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1. EXECUTIVE SUMMARY 

1.1 Purpose 

The purpose of this effort was to develop an execution plan for improving the strategic 
environment (SE) for the U.S. Army modeling and simulation (M&S) community. The plan’s 
focus time frame is through the U.S. Government fiscal year (FY) 03. The study used the 
definition of the SE from the DoD and Army Model and Simulation Master Plans: 

Intemetted simulations that represent activities at a high level of realism from simulations 

of theaters of war to factories and manufacturing processes. These environments may be 

created within a single computer or a vast distributed network connected by local and wide 

area networks and augmented by super-realistic special effects and accurate behavior 

models. They allow visualization of and immersion into the environment being simulated. 

The synthetic environment, therefore, is a highly inclusive concept that consists of: 

• the synthetic natural environment (terrain, oceans, atmosphere, and space) 

• the equipment used to build the SE (computer hardware, communication devices, networks, 
vehicle simulators, display devices) 

• software, databases, and tools for designing, setting up, executing, and monitoring tests and 
experiments and for analyzing the results. 

It can even include live participants, when they function as role players. It is this broad definition 
of the synthetic environment that is used throughout this report. 

1.2 Approach Taken 

The approach taken was to determine the synthetic environment status and needs from: 

• DoD and U.S. Army M&S policies, master plans, investment plans, and vision statements 

• Interviews with a wide variety of senior DOD and U.S. Army officials who are 
knowledgeable about and involved in various aspects of M&S policy, oversight, 
specification, development, and use 

• Other M&S professionals identified through research documents, reports, and referrals. 

The inputs from these sources were consolidated into categories of issues. In parallel, enabling 
technologies were identified that can be applied toward solving the issues. Finally, approaches to 
solving each of the identified issues were defined and documented. 

1.3 Findings 

Seven categories of SE issues were identified and prioritized. The top category was synthetic 
natural environment issues, especially problems relating to building and using terrain databases. 
The need for better representation of the behaviors of individuals, vehicles with crews, units, and 
commanders and their staffs was the number two category. The third category was the need for 
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better interoperability between simulators. Fourth was the need for multipurpose, reconfigurable 
simulators. Better communications network models, and interfacing between C4I systems and 
the SE were fifth. Sixth was the need for more entities, to simulate larger fights between more 
diverse units. The remaining category was tools to make it faster and easier to build the SE, 
design and set up experiments, collect data, and analyze results. 

Eight categories of enabling technologies were identified as being particularly relevant to 
developing an improved SE. They were architectures, computers, display devices, display 
generators, man machine interface devices, networks, software, and tools. 

1.4 Solution Approaches 

Execution plans were defined and documented for applying each enabling technology toward 
solving the SE issues. To effectively implement these plans probably requires a staff of technical 
experts who report to a manager who is above the Program Managers. Someone at that level is 
needed to make and enforce decisions that may impact one program negatively, but are best for 
the programs as a whole. 

Execution plans were defined and documented for addressing each of the SE issues. 
Implementing these plans must be accomplished within the business environment that 
STRICOM operates. This will involve tradeoffs among the priority assigned by higher level 
commanders, the estimated cost, funding availability, the potential benefit, the urgency of the 
time frame, and the development risk. 

1.5 STRICOM SE Leadership Opportunities 

The existence of these SE issues presents an opportunity for STRICOM to provide the leadership 
to solve them for the benefit of the Army M&S community. To accomplish this, STRICOM must 
address five factors: 

1. Implementing the solutions will require an appropriate pool of skilled technical people. 
When there are identified solution approaches, the technical risk is low. 

2. Funding must be found to implement each solution. Since the problems needing to be solved 
span all three domains, the possibility exists to solicit and pool resources from a number of 
organizations. Also, a pricing strategy is needed which allows STRICOM to earn profits on 
the programs it executes. This profit would become working capital and investment capital. 
This is a normal practice in all businesses. 

3. An organizational structure is needed within STRICOM that will encourage, facilitate, and, 
when necessary, enforce cooperative developments and reuse across its projects. 

4. A contractual mechanism is needed between STRICOM and the program funding 
organizations that will allow STRICOM to earn, use, and invest profits. 

5. Develop strategic alliances with key government and industry organizations. 

A broader leadership opportunity would be to move beyond a focus on training simulators and 
seek to provide a common SE and common applications across all three domains: ACR, RDA, 
and TEMO. The broadest leadership opportunity is to provide well-organized, high quality 

2 

Use or disclosure of information on this page is subject to the restrictions referenced on cover of this report 

UNCLASSIFIED 


ADST-II-CDRL-SESP-9800192 

7/15/98 


leadership to the entire M&S community, and target becoming the Simulation Center for the 
Army. 
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2. INTRODUCTION 

2.1 Objectives 

There were two contractual objectives for this study effort. The first was to provide analysis and 
data for a plan to guide the direction of the synthetic environment (SE) development through the 
POM 98-03. The second was to provide STRICOM with a mid and long-range, high level 
strategic plan for synthetic environment development and execution. 

Research and data gathering were conducted to help identify the Army's major SE needs for FY 
98-03. That information was analyzed, consolidated, and prioritized within the constraints of the 
study. Completion of that activity fulfilled the first objective. Plans were then generated for how 
to meet each of the identified major SE needs. These plans are documented in this report and are 
also summarized in a companion viewgraph presentation. Completion of that activity fulfilled 
the second objective. 

2.2 Methodology 

To put the project into a proper organizational context, the first step taken was to acquire and 
study the U.S. Army models and simulations (M&S) management policies, master plans, 
investment plans, and vision statements. 

The next step was to determine the Army's SE needs for FY 98-03. This information was not 
contained in the documents that had been examined. The strategy chosen was to interview a wide 
variety of key senior DoD and U.S. Army officials who are knowledgeable about and involved in 
various aspects of M&S policy, oversight, specification, development, and use. A list of such 
people was compiled and refined with assistance from The U.S. Army Simulation, Training, and 
Instrumentation Command (STRICOM). A letter was then sent by STRICOM to each identified 
official, requesting their participation in a short telephone interview. A list of sample questions 
was enclosed with the letter. Each proposed interviewee was then telephoned to request a 
specific time to conduct the interview. The interviews were conducted over a six-week period, 
beginning in late January, 1998. During that time, the initial list of people to interview was 
expanded from information in research documents, reports, the M&S master plans, and from 
referrals. 

The respondents were very cooperative and provided valuable insights and information. Their 
inputs were consolidated into categories of issues. The issues were prioritized based on the 
approximate number of people who mentioned the issue. In this report, the inputs have not been 
identified with particular respondents. We planned to keep the comments anonymous, believing 
it was important to encourage the respondents to be candid. 

In parallel with conducting the interviews and beginning to identify, consolidate, and prioritize 
the SE issues, a number of additional relevant documents were examined. Writing of this report 
began while the interview process was still underway. When enough information had been 
acquired to identify and clarify a topic, a preliminary draft of the corresponding subsection was 
written. Those drafts were updated as additional relevant information was obtained. 
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2.3 Organization of the Report 

The report is organized as follows: Section 1 discusses the objectives and describes the 
methodology used in this study. Section 2 establishes the synthetic environment context by 
providing a brief history of Army M&S and a definition of the synthetic environment. An 
overview of what can be modeled in the SE, the SE issues which were identified, and the 
enabling technologies which can help address those SE issues are presented in Section 3. Section 
4 discusses the STRICOM business context, describes actions to take advantage of the enabling 
technologies, and contains plans for addressing the SE issues. Section 5 summarizes the findings 
and methods to begin implementing the execution plans. A copy of the letter introduction from 
STRICOM to each proposed interviewee is contained in Appendix A. Appendix B is a list of the 
names, organizations, addresses, and phone numbers of the interviewees. Appendix C is a list of 
the referenced documents. Appendix D is a glossary of acronyms. 

2.4 Contributors 

Dr. Eugene N. Lowe, SAIC, and Dr. Robert M. Cox, SAIC, were the primary authors of this 
report. Additional contributors were John C. Eberle, SAIC and Jame E. Shiflett, SAIC. 
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3. SYNTHETIC ENVIRONMENT CONTEXT 
3.1 Framework of Army Modeling and Simulation 

This section includes a brief history of U.S. Army Modeling and Simulation (M&S). The 
synthetic environment is defined. Three viewpoints of the SE - operational, system or program, 
and technical are explained. 

Prior to 1990, the field of M&S was marked by fragmentation and limited coordination of 
activities across key communities, e.g., across Service lines and across functional areas. 
Recognizing these problems, Congress directed the Department of Defense (DoD) to "... 
establish an Office of the Secretary of Defense (OSD) level joint program office for simulation 
to coordinate simulation policy, to establish interoperability standards and protocols, to promote 
simulation within the military departments, and to establish guidelines and objectives for 
coordination of simulation, wargaming, and training" (Senate Authorization Committee Report). 
The Defense Modeling and Simulation Office (DMSO) was subsequently established to be that 
organization. 

In 1991, the Deputy Secretary of Defense assigned overall management responsibility of all DoD 
M&S to the Under Secretary of Defense for Acquisition. This office established the DoD 
Executive Council on Modeling and Simulation (EXCIMS) who developed a vision for DoD 
M&S. This vision was intended to help focus the DoD's M&S community on its core functions 
and to focus on applications that would enhance overall M&S capability. 

These ideas were incorporated by the EXCIMS into the DoD M&S vision: 

1. Defense modeling and simulation will provide readily available, operationally valid 
environments for use by the DoD Components: 

a. To train jointly, develop doctrine and tactics, formulate 

b. operational plans, and assess warfighting situations. 

c. To support technology assessment, system upgrade, prototype and full-scale 
development, and force structuring. 

2. Furthermore, common use of these environments will promote a closer interaction 
between the operations and acquisition communities in carrying out their respective 
responsibilities. To allow maximum utility and flexibility, these modeling and simulation 
environments will be constructed from affordable, reusable components interoperating 
through an open system architecture. 

Four major trends have established the conditions for the current status of Army M&S 
management: 

• First, the continuing revolution in information technologies has widened the opportunity for 
using M&S, often enabling organizations to use M&S developed by others. This has 
increased the number of users of Army M&S to the point that M&S are ubiquitous, touching 
almost all aspects of Army operations. 
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• Second, this same technology revolution has engendered an infrastructure that permits 
greatly increased sharing of M&S among distant developers and users. 

• Third, the current trend of increased budgetary constraints has emphasized the need for more 
effective and efficient development, use, and sustainment of Army M&S. 

• Finally, the evolution towards the Army as part of a Joint force has energized the need to 
ensure Army M&S can interoperate with other Service and Department of Defense 
capabilities. 

In response to the challenges created by these trends, the Army leadership created a new 
management structure for Army M&S that includes the Army Model and Simulation Office 
(AMSO) as the central management office for M&S. The AMSO is part of the overall M&S 
management structure now in place to focus M&S investments more efficiently. The vision for 
the M&S community is promulgated by the Army Model and Simulation Executive Council 
(AMSEC) and the AMSO with the three domain managers. The Army manages M&S by 
domains based on functional, rather than organizational lines. The three domains are: Advanced 
Concepts and Requirements (ACR), Research, Development and Acquisition (RDA), and 
Training, Exercises and Military Operations (TEMO). 

3.1.1 Army M&S Domains 

Each of the three domains established supporting structures to guide their investments. Each 
domain's plans outline its approach to meeting the strategic level guidance. Together, the 
strategic guidance and domain supporting guidance establish the general direction for M&S 
investments across the Army and within each domain. All Army M&S activities fall either under 
the purview of a single domain or are cross-domain activities. The example activities, 
simulations, and simulators listed in Table 1 are predominately used in the corresponding 
domain, but are by no means exclusive to that domain. Individual organizations determine the 
proper domain(s) for their requirements. 

Table 1. The Army’s M&S Domains with Example Activieies and Systems 


Domain 

Domain Activities 

Simulations/Simulators 

Advanced Concepts and 
Requirements (ACR) 

Force Planning 
Developing Requirements 
Warfighting Experiments 

Reconfigurable Simulators 
Constructive Models 

Research, Development, 
and Acquisition (ACR) 

Basic/Applied Research 
Weapons System 
Development 

Test and Evaluation 

System Prototypes 
Engineering and Physics 
Models 

Training, Exercises, and 
Military Operations 
(TEMO) 

Individual and Collective 
Training 

Joint and Combined 
Exercises 

Mission Rehearsal 
Operations Planning 

System Simulators 
Training Simulations 
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3.1.1.1ACR Domain 

The ACR domain supports the Institutional Army's core capabilities of Direct and Resource the 
Force and Develop the Force. The principal focus of the ACR domain is providing strategic 
direction, concept development, requirements development, and force planning. ACR domain 
activities depend upon insights and quantitative data from M&S for analyzing strategic, 
operational, and tactical operations in war, conflict, and operations other than war. The primary 
products of these activities are strategies, warfighting concepts, mission needs, doctrine, 
requirements, executable plans, and affordable programs. 

The ACR domain addresses four analytical categories where M&S is significant: strategic and 
operational force analysis, tactical force analysis, modernization analysis, and other unique 
analysis. They have established five domain objectives for the FY 98-03 POM: 

1. Using M&S as a primary tool, validate Army operational requirements, structure, and 
doctrine at strategic, tactical, and entity levels. 

2. Support acquisition reform and participation in Integrated Concept Teams to define Mission 
Needs Statements and Operational Requirements Documents. 

3. Assess C4I requirements and integrate simulations and proven C4I systems for a multi- 
echeloned digitized force. 

4. Network key M&S capabilities to support existing and proposed major weapon systems 
developments in a common synthetic environment for Force XXI. 

5. Support cost, production, and maintenance assessment for joint warfighting capabilities. 
Support development and implementation of the Joint Warfare System (JWARS). 

3.1.1.2 RDA Domain 

The RDA domain supports the Institutional Army's core capability of Sustain the Force. The 
principal focus of the RDA domain is supporting research, development, system acquisition, and 
logistical support, plus advancing the art and science of the Army's M&S across all domains. 

The RDA M&S applications run the gamut from highly detailed analysis of physics based 
characteristics of the proposed system to less detailed analysis of applications of emerging 
technologies. RDA uses models and simulations to support their missions of research and 
development, system acquisition, test and evaluation, and logistical support, as well as to 
advance the state of the art of the models and simulations used in all three domains. Their M&S 
objective is to provide support for the four elements which make up the RDA effort: major 
systems (Acquisition Category I and II programs), science and technology programs (Advanced 
Technology Demonstrations and Advanced Concept Technology Demonstrations), test and 
evaluation programs, and non-major systems (Acquisition Category III programs). 

3.1.1.3 TEMO Domain 

The TEMO domain supports the Institutional Army's core capabilities of Develop the Force, 
Generate and Project the Force, and Sustain the Force. The principal M&S focus of TEMO is 
providing capabilities that support the maintenance of a trained and ready force. TEMO domain 
activities include individual, crew, and collective training events and M&S support to military 
operations at the tactical and operational levels using a variety of networked and stand-alone 
live, virtual, and constructive M&S capabilities. 
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The TEMO domain uses the SE to support training, exercises, and mission rehearsal to prepare 
the commanders, soldiers, and units of the Army for quick, effective and joint responses to 
worldwide contingencies. The TEMO M&S objectives are: 

1. Support the Army’ s training architecture, 

2. Manage the development and fielding of Training Aids, Devices, Simulators, and 
Simulations (TADSS), and 

3. Ensure an M&S infrastructure is embedded into future training systems to support training, 
mission rehearsal, and operations planning. 

All three domains need and use synthetic environments to support their missions. It is 
noteworthy, therefore, that none of the domains has the responsibility for an objective to 
develop, maintain, or make available to itself and others the core infrastructure of the SE. This 
could be one of the reasons that it is difficult to fund and to perform this task. To proactively 
seek a solution to this is a natural role for STRICOM. 

3.1.2 Army M&S Masterplans 

The Army Modeling and Simulation (M&S) Master Plan (1995) and The DoD M&S Master Plan, 
1996 define six fundamental objectives which form a framework for the Army M&S 
infrastructure and a foundation for Army M&S development. These objectives address the 
technical groundwork aspects needed to ensure commonality and foster interoperability of Army 
M&S. These fundamental objectives apply to each domain and address primarily how M&S 
should be developed: 

Objective 1: Provide a common M&S technical framework 

Objective 2: Provide timely and authoritative environmental representations 

Objective 3: Provide authoritative representations of systems 

Objective 4: Provide authoritative representations of human behavior 

Objective 5: Provide an M&S infrastructure to meet developer and end-user needs. 

Objective 6: Share M&S benefits 

These Army and DoD M&S objectives form a framework for M&S investment planning and 
support the achievement of domain M&S objectives. The 1995 Army M&S Master Plan 
establishes a process for developing technical M&S standards to meet fundamental Army M&S 
objectives. This standards development process, which has now been underway for several years, 
builds technical M&S procedures, algorithms, and other appropriate M&S techniques, and 
increases commonality and reuse potential. As the standards are developed, the Army moves 
progressively closer to achieving the Army and DoD objective M&S environment. 

Investment in M&S provides a critical underpinning for a variety of Army missions from 
designing a future force and building the systems and doctrine for that force, to training and 
operating that force. Careful planning for M&S resources enables organizations throughout the 
Army to benefit from each others' expertise and products, while minimizing duplication. 

The second edition of The Army M&S Master Plan (1995) presented the Army's plan for 
embracing the power of Distributed Interactive Simulations (DIS). In the three years since the 
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publication of that plan, significant changes have occurred in the M&S community. The 
standards for the DoD common technical framework, most notably the High Level Architecture 
(HLA), began supplanting the DIS standards for interoperability. The leadership of the Army 
strengthened the management roles of the domains. Changes also occurred in the broader 
community served by M&S. The publication of Joint Vision 2010 and Army Vision 2010 
established new concepts and a new lexicon for describing future capabilities. The Army After 
Next program started to investigate the major factors that will affect the Army in the years 2010- 
2025. As each of these changes shed more light on the Army's future, they present new 
challenges for the M&S After Next. 

3.2 Synthetic Environment Defined 

Both the DoD M&S Master Plan, 1996 and the Army M&S Master Plan, 1997 have the 
following definition for the synthetic environment: 

Intemetted simulations that represent activities at a high level of realism from simulations 
of theaters of war to factories and manufacturing processes. These environments may be 
created within a single computer or a vast distributed network connected by local and 
wide area networks and augmented by super-realistic special effects and accurate 
behavior models. They allow visualization of and immersion into the environment being 
simulated. 

Thus the synthetic environment is a highly inclusive concept. It includes the synthetic natural 
environment (terrain, oceans, atmosphere, and space). It includes the equipment used to build the 
SE (computer hardware, communication devices, networks, vehicle simulators, display devices). 
It includes the software, databases, and the tools for designing, setting up, executing, and 
monitoring tests and experiments and for analyzing the results. It can even include live 
participants when they function as surrogates or role players. It is this broad definition of the 
synthetic environment that has been used throughout this report. 

Figure 1 illustrates this definition of the synthetic environment as it applies to Army models and 
simulations. Four of the blocks in the center of the figure represent the major types of military 
entities in the synthetic environment: Command, Control, Communication, Computers, and 
Intelligence (C4I) systems, Vehicles on test/training ranges (live), Semi-Automated Forces 
(SAF) and Manned Simulators (virtual), and simulations consisting of Computer Generated 
Forces (CGF) and/or Semi-Automated Forces (constructive). They send and receive control 
information, data, voice, video, and interactions through the interconnections function. 

At the top of Figure 1 are shown the support functions. These facilitate the design, setup, 
execution, and monitoring of tests, exercises, and experiments. They also provide for data 
collection, and they support After Action Reviews (AAR) and analyses. At the bottom of the 
figure the live participants are shown. Some of these may be surrogates or role players. Others 
could be operators, controllers, users, trainees, developers, experimenters, observers, or analysts. 
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Figure 1. Top Level Block Diagram of the Synthetic Environment 


3.3 Three Perspectives of the Synthetic Environment 

Because of differences in their areas of responsibility, each organization within the Army has 
different areas of interest relative to the synthetic environment. This results in a variety of 
perspectives of the SE. This report considers three such perspectives: the operational perspective, 
the system or program perspective, and the technical perspective. 

3.3.1 Operational Perspective 

The Operational perspective is that of the users of the synthetic environments. These include 
commanders of forces at various echelons, the staff who provide information to them, battle 
laboratory directors, researchers, analysts, instuctors, and trainers. Their concern is about which 
aspects of the operational forces and the environment can and cannot be represented in the SE. 
Of those aspects represented, they are concerned about how well they can be represented. 

Within the Army, different organizations have their own areas of responsibility, and utilize 
synthetic environments in different ways to help meet those responsibilities. Because of these 
differing perspectives, various organizations have their own view of the capabilities, limitations, 
and shortfalls of the SE. 

Those with the operational perspective often do not understand or appreciate that requiring 
specific capabilities in a synthetic environment affects the cost, schedule, and complexity of the 
systems that comprise that SE. 
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3.3.2 Systems or Program Perspective 

The Systems or Program perspective is that of program managers and systems engineers who are 
responsible for particular programs, i.e., SAFs, CGFs, and manual simulators. Their focus is on 
the required capabilities of their particular system and on the system's role in the SE. They are 
concerned about the definition of the system interfaces, the information needed from the SE, the 
information which must be provided to the SE, how that can be made to happen, and the 
resulting capability of the system when operating in the SE. They view their system as a task 
which must be accomplished within the confines of its requirements, schedule, and funding. 
Program managers often do not understand the ramifications that system design decisions will 
have later on the ease or difficulty of using the system, of making modifications and 
enhancements, and of its reuse by others. 

3.3.3 Technical Perspective 

The Technical perspective is that of the Army and contractor design engineers who are tasked 
with implementing and integrating the pieces which comprise either a particular system or a 
synthetic environment. They view the system and the SE as consisting of its constituent parts 
(e.g., computers, software, object models, data representations, operator controls, display 
devices) and their interconnections (e.g., interfaces, communication devices, networks). They are 
very much interested in the technological advances that can provide the means to build a better 
system, enhance the capabilities of existing systems, or improve the overall synthetic 
environment. They often do not understand the ramifications that including or not including 
specific technical capabilities has on users in the operational domains. 

There is a need for coordination and cooperation among the operational users, the program 
managers, and the technical implementers. Fostering and facilitating this is a natural role for 
STRICOM. 
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4. FINDINGS 

This section defines what can be modeled in the synthetic environment, identifies the SE issues 
that must be solved to achieve significant improvements in the current state-of-the-art, and 
identifies the enabling technologies that support developing those solutions. 

Table 2. Framework For What Can Be Modeled 


Time 

Frame 

Applications 

Scope 

Force 

Type 

Echelon 

Phases of 

Operation 

Elements To Be 

Modeled 

Current 

(TEMO) 

Emerging, 

Visionary 

(ACR, 

RDA) 

Analytic 

Applications 

Doctrine 

Training 

Leader 

Development 

Organization 

Materiel 

Soldiers 

Army 

Joint 

Coalition 

Opposing 

Force 

Theater 

Vehicle 

Soldier 

Force Projection 

Cycle 

Alert 

Mobilization 

Early Entry 
Operations 

Operations 

Sustainment 

Recovery 

Redeployment 

Peacetime 

Sustainment 

Vehicles 

Units 

Forces (Collections of 
Units) 

C4I 

Tactics and Behaviors 

Battlefield Environment 
(SNE) 

Terrain 

Weather 

Manmade Objects 
Weapons Effects 
Countermeasures 
Effects 

Specific Locations 
(Identification of 
Battlespace) 


4.1 What Can Be Modeled 

It is not possible to know exactly what the Army will be required to model and simulate in the 
synthetic environment from FY 98 - FY03. It is not possible to know exactly who or how the 
Army will be required to fight. Due to these two unknowns, it is not possible to know exactly 
what new military operations require research and development, analysis, or training. In spite of 
these unknowns, it is possible to state the likely M&S capabilities that will be required within the 
Army from FY 98-03. Figure 1 shows a framework for the things that can be modeled in the 
synthetic environment. There are six categories shown: time frame, applications scope, force 
type, echelon, phase of operation, and elements to be modeled. Each category addresses a 
different aspect or dimension of what can be modeled in the SE 
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4.1.1 Time Frame 

At a macro level, what can be modeled in the synthetic environment are: 

• The current systems 

• The emerging systems 

• The visionary systems. 

Modeling current systems (vehicles, units, command centers, and so on) and their capabilities is 
an on going activity in the TEMO domain. If it already exists and is relevant to the TEMO 
domain, there is a need to model it in an appropriate level of detail. Next, there is the need to 
model emerging systems. Modeling future systems, systems that are under development or near 
deployment, is done in the ACR domain, and the RDA domain. By the time a system is 
deployed, its model is transitioned to the TEMO domain. Models of visionary systems and 
experimental capabilities are needed to support the work of people in the ACR and RDA 
domains, as they investigate new devices, tactics, techniques, and procedures for the operational 
forces. 

4.1.2 Applications Scope 

The modeling of current, future, and visionary systems will be done to investigate options, solve 
problems, and develop new approaches for the following categories of analytic applications: 

• Doctrine 

• Training 

• Leader Development 

• Organization 

• Materiel 

• Soldiers 

The synthetic environment should, therefore, support modeling and simulation for each of these 
applications. 

4.1.3 Force Type 

The synthetic environment should support a broad spectrum of Army, joint, and coalition forces, 
and the opposing forces for all of these. 

4.1.4 Echelon 

There is a need for the SE to support simulations at all echelon levels: Theater, Army, Corps, 
Division, Brigade, Battalion, Company, Platoon, and the individual vehicle and soldier. The 
intended use of the simulation (e.g., educating commanders or training soldiers) strongly affects 
the number of entities that need to be represented, their degree of aggregation, the level of detail 
of the individual entity models, and the field of view and visual resolution needed from the 
display devices. 

4.1.5 Phases of Operation 

The Army has defined the Force Projection Cycle, which categorizes the activities of units from 
peacetime, to alert, to deployment, through operations, and back to peacetime sustainment. 
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Simulation of each phase of operation defined in the Force Projection Cycle should be supported 
by the synthetic environment: 

• Alert 

• Mobilization 

• Deployment 

• Early Entry Operations 

• Operations 

• Sustainment 

• Recovery 

• Redeployment 

• Peacetime Sustainment 

Ideally, the SE would provide tools so that the simulation moves seamlessly between phases, and 
the effects of events in one phase properly affect downstream phases. 

4.1.6 Elements to be Modeled 

The following are the categories of elements or battlefield entities which should be modeled: 

• Vehicles 

• Units 

• Forces (Collections of Units) 

• Command, Control, Communication, Computers & Intelligence (C4I) 

• Tactics and Behaviors 

• Battlefield Environment (Synthetic Natural Environment) 

• Specific Locations (Identification of the Battlespace) 

The term Vehicles includes ground and air vehicles with their weapons systems. Units consist of 
collections of vehicles and soldiers. Forces consist of collections of units. 

The C4I structure consists of the communications devices and networks, the voice and data 
traffic, and the collection and distribution of intelligence information. Tactics and Behaviors 
address how commands are issued and executed within the confinement of the battlefield 
environment. Included within the Battlefield Environment category are the elements of terrain, 
weather, manmade objects, countermeasures, and weapons effects. Weapons effects include fire, 
smoke, and damage to entities on the battlefield. Specific Locations consist of appropriate 
resolutions of Battlefield Environment information at actual locations throughout the world, 
including test and training ranges. 

4.2 Major SE Issues 

A significant part of this effort was spent identifying the SE issues which most need to be 
addressed. The results are summarized in Figure 2 in an approximate priority order. Issues 
related to representing the synthetic natural environment (SNE) were determined to be the most 
important. These were followed closely by representation of behaviors, interoperability, 
reconfigurability, and C4I. Finally, there were numbers of entities and tools. 
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Figure 2. Major Synthetic Environment Issues 


4.2.1 Synthetic Natural Environment 

The U.S. Army Training and Doctrine Command (TRADOC) has identified the SNE issue as 
important for the synthetic environment. The Close Combat Tactical Trainer (CCTT) program 
worked on the issue. They correctly understood that the sparseness and regularity of the 
SIMNET database had a significant negative impact on training. Another negative impact came 
from the lack of objects, such as trees, on the terrain. The CCTT program sought to develop a 
much more realistic synthetic training environment that would provide the same influence on 
tactics and relative effectiveness as in the real world. With this background in mind, it is 
necessary to define what constitutes the SNE, how SNE representations are used, and to describe 
some of the SNE issues raised in the interviews. 

4.2.1.1 Definition of the SNE 

The definition of the synthetic environment comes from the DoD and Army M&S Master Plans 
and means more than just the visual scene representation. It is the total representation of the 
battlespace created to support a training exercise. Within the synthetic environment there are two 
categories of objects: the warfighting entities present in the battlespace and the natural 
environment with its cultural and natural features. The natural environment covers all 
environmental domains: terrain, ocean, atmosphere, and space. When simulating these features, 
it is important that their geographic location is as accurate as possible. 

4.2.1.2 How the SNE Representations Are Used 

The representations of the synthetic natural environment include the data and attributes 
describing all of the objects and features in the battlespace. They also include data that is used to 
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improve computational performance related to the level of detail in the simulation. Data types 
now in the synthetic natural environment databases can be used to improve the fidelity of the 
simulation. When new data types are added, they must be correlated with the existing data types, 
so that the result is an integrated, single, coherent representation in the simulation. This is 
particularly important when two or more simulations federate for a simulation. 

To help put the remainder of this discussion in perspective, it is necessary to examine the SNE 
generation process. Figure 3, SNE Interactions, shows one way to represent what is happening 
between the computer models that comprise the SNE. These models are mathematical 
representations of entities, objects, or situations. The models are combined with each other and 
with an infrastructure to create a simulation. Software models usually cannot execute by 
themselves. They need inputs and data from other models. The entities represented by these 
models are also referred to as Mission Space Objects (MSO). 


SNE Representation 


Com ponent 
M odels 


B ehavior 
M odels 


D y n a m i c 
SNE DB 



Ground 
T ruth 
SNE DB 


Dynamic SNE 
Model 

SNE Impacts 


In tern a I 
Dynam ics 


Environmental Data and Models 



Figure 3. SNE Interactions 


A version of the conceptual model above was proposed and can be found in the draft Joint 
Simulation System (JSIMS) Technical Notice #9. The original version has been modified here to 
explicitly show the feedback mechanisms. This figure indicates how the component and behavior 
models interact with the SNE representations. It is evident that there is input directly from the 
SNE representation into the behavior models and feedback from the behavior models to the SNE 
representation. The interactions between the various models is facilitated by a common data 
exchange format. Previously, proprietary databases were developed and the reuse of these data 
was limited. To alleviate this interoperability problem, a program named Synthetic Environment 
Data Representation and Interchange Specification (SEDRIS) was established. SEDRIS is not a 
database, but is an interchange format between databases and/or models. Using the SEDRIS 
format will allow multiple users to access and exploit SE representations developed for other 
simulation systems. 
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The Mission Space Objects are the actual entities in the real world being modeled during runtime 
to create the synthetic battlespace. A non-exhaustive list of MSOs includes sensors, aggregates, 
command and control decision-makers, and the environments, such as the weather and terrain. 
Figure 4 is a flow chart of the MSO process. The classifying of the MSO occurs in steps 1-3. 
Step 1 examines its physical presence. Is it physically measurable? Does it have one or more 
physical locations associated with it? The second step asks if the entity is a military, civilian, or 
biological system. A subset of this is to determine if it is a manmade object and if it can move. 
The biological portion is concerned with all living things except plants. If the entity is neither 
type 1 nor 2, then the third question is whether the entity is a military or civilian control measure. 
An example of a military control measure is controlling the airspace or the forward edge of the 
battle area. Examples of civilian control measure are administrative boundaries, shipping lanes, 
and civilian air routes. The SNE MSO has now been identified and classified. There are two 
remaining steps which include determining whether the MSO is man-made or if it occurs 
naturally. A man-made MSO is like an acoustic noise or RF emission, whereas, a naturally 
occurring MSO is like leaves falling or wind creating dust. This whole procedure is more fully 
discussed in JSIMS Technical Notice #10. 
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Figure 4. MSO Determination and Classification 
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4.2.1.3 SNE Issues Raised in the Interviews 

Many of the interviews were very specific about how the process of SNE model development 
should take place. In a phrase, the models need a higher degree of fidelity. Real physical models 
should be integrated into the simulations and higher resolution simulators should be developed. 
At the same time, the developments should be portable from one simulation to another. The 
proprietary solution should be avoided. 

Common formats should be developed and fielded. This includes the SEDRIS work mentioned 
above to enable the interoperability of databases and data sets. Within the realm of 
interoperability for the SNE, all models should be made HLA compliant. This may require some 
models to be re-engineered to meet near real time needs. 

If one phrase could sum up the general consensus of the SNE interviewees, it is that more 
physics based models need to be incorporated into the simulations and a common interchange 
format is needed to ensure interoperability. 

4.2.2 Representation of Behaviors 

The representation of behaviors follows closely behind the SNE as a major issue and concern 
with the individuals interviewed. This correlates well with the M&S Master Plan and its six 
objectives. One of those objectives spoke to providing authoritative representation of behaviors. 
Areas of interest mentioned in the interviews included representing individuals, vehicles with 
crews, units, and staffs. This concept is evident in Figure 2 SNE Interactions. In this figure there 
are interactions between the SNE and the behaviors, between the component models (sensors, 
weapons, etc.) and the behaviors, and the behaviors in turn affect the SNE (via vehicle tracks, 
smoke deployed, weapons fired, etc.) 

4.2.2.1 Important Behaviors 

The final step in Figure 3 MSO Determination and Classification provides input into the 
behavior models. There are two basic types of behaviors. The first is man-made. The developer 
must define the behavior associated with the physical functionality of an object, i.e. how it 
affects sensory systems or movement. If an object is a naturally occurring one, the developer has 
to model this second type, called natural behavior. There are two basic categories within the 
naturally occurring behaviors: internal dynamics and interactions. With internal dynamics, 
behavior is affected over time. An example of this is the change of seasons. Interactions can 
occur between MSOs. The developer must develop a mechanism to provide an assessment of the 
result of the interaction. An example of this is when a munition strikes the ground instead of its 
target. The physical state of the terrain changes and needs to be modeled. 

Now refer back to Figure 2 SNE Interactions. The SNE Working Group had proposed the 
original figure to illustrate the important relationships between the environment, the component 
models, and the behavior models. It was also intended to show the ultimate effect that the 
environment has on the behaviors. There are several important behaviors that the environment 
can affect. They range from scouting, marching, and occupying to fire, search and find, and 
tracking. Such behavior models need to be developed for individuals, vehicles with crews, units, 
staffs, and any other human controlled entity that is proposed to be modeled in the SE. 
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4.2.2.2 Behavior Issues Raised in the Interviews 

From the many interviews, there is the desire to easily modify the represented behaviors. This 
modification can occur for two reasons. The first is that the individual, vehicle, unit, or staff 
behavior may need to be modified, because a weapon affected them. The second reason may be 
that they were affected by an outside source. This outside source would include modification by 
the game director to achieve a desired learning objective. 

A number of the interviewees were adamant about the need for increasing the fidelity of the 
physical models. They also spoke of the need to make the environment more credible and to 
couple sensors with the environment and the environment with the troops. That also applies to 
the behaviors. The simulation needs the ability to react to the changing conditions, including 
changing environmental conditions. The interviewees distinguished between two types of 
changing conditions. The first conditions are environmental. This includes weather effects such 
as rain, clouds, temperature, and so on. These conditions can impact behaviors. The second 
changing conditions are the impact of actions by individuals, vehicles, and units. When the 
environment changes as a result of such actions, it should be reflected in the simulation to ensure 
the proper degree of realism. Component models can also change the environment because a 
weapon can impact an individual, vehicle, or unit thus changing the simulation and the behavior. 

As has been briefly outlined above, there are many impacts of the behaviors that are not 
represented realistically. This loss of realism can lead to simulations that may not meet the 
analysis or training objectives. One outcome could be a deficiency in the knowledge acquired by 
individuals being trained. This is one reason that many of the interviewees expressed the need for 
more accurate representation of the behaviors. Another reason is so that SAFs and CGFs can 
better represent the behaviors of commanders, staffs, and units at higher echelons. 

4.2.3 Interoperability 

This area was a major issue identified by those interviewed. Comments ranged from the need to 
integrate diverse simulators not designed to operate together, to designing future simulators for 
interoperability. The problems of interoperability can be of a hardware or software nature. They 
manifest, for example, when corresponding hardware components cannot be connected together 
or the databases used by one simulation are incompatible with that of another simulation. 
Addressing this in the past led to many one-of-a-kind software or hardware solutions that are 
often costly, proprietary, or both. 

Also mentioned in the interviews were the difficulties in having a “fair fight” between two 
simulators. This can happen, for instance, if simulator A has more robust algorithms for 
depicting shadows, terrain, and other common obscurants, than simulator B. It can also happen 
due to differences in representing the terrain database. Vehicle A could be behind a hill in 
relation to Vehicle B, but Vehicle B could be in plain view to Vehicle A in its simulation. 

4.2.4 Reconfigurability 

A point that was raised in several of the interviews was the need to design simulations or 
simulators with combined capabilities. Instead of having individual simulators for each type of 
training (e.g., a tank gunnery trainer and a separate tank driver trainer), have a reconfigurable 
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simulator that can replicate many different types of training (gunnery and driver training for 
tanks, armored personnel carriers, self-propelled artillery, etc.) 

Another aspect of reconfigurability is reprogramming specific vehicle capabilities for different 
experiments, exercises, or training missions. This includes reconfiguring the software to create 
different types of C4I displays. 

4.2.5 Command, Control, Communication, Computers, and Intelligence (C4I) 

There were two categories of issues identified relative to C4I. They were: 

• Representation of communication networks,+ bandwidth, and loading, and 

• Integration of C4I systems with the SE. 

4.2.5.1 Representation of Communication Networks 

Communications network simulation is lacking in many models and simulations. It is common to 
model perfect communications and unrealistically wide bandwidths. When this is done, the 
delays, bandwidth limitations, and line of sight restrictions of real world communications are not 
present in the simulation. One result is that the participants in a test or exercise can achieve 
overly optimistic results and are being trained to expect much better communications than are 
achievable in a real operation. They are, therefore, not learning how to work within and 
compensate for the limitations of real world communications systems. 

The Army's communication system architecture is changing from the present packet switched 
architecture to the Warfighter Information Network, which is looking at Asynchronous Transfer 
Mode (ATM) switching. This will affect the modeling of future communications. 

4.2.5.2 Integration of C4I Systems into the SE 

Current C4I systems were not designed to facilitate interfacing into the SE. Many were not even 
designed to facilitate interoperating with other dissimilar C4I systems. The Joint Technical 
Architecture is an on-going effort to define C4I interface, protocol, message format, and data 
format standards to help alleviate this problem for future C4I systems. 

For current systems, it is necessary to engineer specific interfaces between each type of C4I 
system and the SE. Most of the recent interfaces have been software translators, like Modular 
Reconfigurable C4I Interface (MRCI) and Tactical Simulation Interface Unit (TSIU). There is a 
need for a more generalized solution. There is also a need for a cooperative effort by C4I 
developers and SE developers to work toward facilitating particular solutions while trying to 
develop more generalized solutions for interfacing between C4I and the SE. Adhering to JTA 
would simplify, but would not guarantee, this interoperability. 

4.2.6 Number of Entities 

The battle laboratories expressed the need to be able to conduct larger fights to support their 
missions to develop new tactics, techniques, and procedures against potential adversaries. As 
computer power (processor speed, memory, and storage) and network bandwidth increase, it is 
possible to simulate larger and larger numbers of entities. This issue is also closely related to the 
issue of representation of behaviors (Section 3.2.2). A companion aspect of the number of 
individuals, units, vehicles, and staffs that are represented in the simulation is the level of detail 
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of representing each entity. This must be balanced with the computational power available in the 
simulation. Another aspect is the resolution of the visual image of an entity. The closer the entity 
is to a live participant in the SE, the higher the resolution that is needed. Conversely, the farther 
an entity is from the main focal point of the simulation, the lower the resolution of the entity can 
be. Taking advantage of this fact could allow for creating more diverse units, which allows for 
higher fidelity simulations within the same computer and display generator capabilities. 

4.2.7 Tools 

A tool can be any combination of hardware or software that helps achieve the objective of the 
simulation. Tools can be used to design simulations, develop simulations, set-up simulations, 
collect data on simulations, and analyze data from simulations. These are the most common uses 
for tools in the SE. Another class of tools help the Program Managers plan and manage 
programs. There are a number of commercial off the shelf (COTS) tools which are available to 
aid in planning and managing programs. 

Most of the interviewees who mentioned tools were interested in tools to support tests, exercises, 
and experiments. There is a strong need for tools that can facilitate the setup, execution, 
monitoring, and evaluation of the simulation. When the simulation is completed, there is a need 
for standard, easy to use tools to better evaluate the success of the simulation. 

4.3 Enabling Technologies 

As shown in Table 3, there are eight major categories of enabling technologies that support the 
development of solutions to the issues discussed in Section 3.2. Advances in some of these 
categories are driven entirely by needs in the commercial arena, e.g., non-militarized computers, 
display devices, display generators, networks, computer operating systems, and software 
development and analysis tools. The Army, as a customer, is so small relative to the commercial 
market that it cannot expect to impact any of these developments. However, the Army must 
remain alert to what is happening in the commercial sector, and make optimal use of appropriate 
commercial off the shelf (COTS) products as they become available. The remainder of the 
enabling technologies will require investments by the Army to develop the needed items. This 
Army investment is required, because there is no viable commercial market for these products, 
i.e., SE architecture, custom man machine interfaces, many military specific software 
applications, and most of the tools. 
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ENABLING TECHNOLOGIES 


Architectures 

Computers 

Display Devices 

Display Generators 

Man Machine Interfaces 

Networks 

Software 

• Operating Systems 

• Application Program Interfaces 

• Applications and Models 

• Graphical User Interfaces 

• Databases 
Tools 


Table 3. Enabling Technologies 


4,3.1 Architectures 

There are several levels of architecture to address. At the highest level is the architecture of the 
overall synthetic environment. The SE architecture defines the functional partitioning, as shown 
in Figure 1, Top Level Block Diagram of the Synthetic Environment. It defines the interfaces, 
the information that passes between the partitions, and how that information is passed. The major 
distributed simulation architectures to date have been the Simulation Network (SIMNET), the 
Distributed Interactive Simulation (DIS), the Aggregate Level Simulation Protocol (ALSP), and 
the High Level Architecture (HLA). There is some preliminary thought being given to what the 
architecture after HLA might be. Some are postulating that it will be a composable architecture 
that would enable a user to rapidly define, set up, execute, and analyze a SAF or CGF scenario. 
Setup would be done by building vehicles, units, and behaviors by selecting and combining 
objects from libraries of reusable models. Execution and analysis would also use library tools. 

The next level of architecture is within each of the functional blocks in Figure 1: the C4I, the 
manned simulators, the SAFs, and the CGFs. The architecture within each block determines how 
easy or difficult it is to: 

• Initially embed functional capabilities within those blocks. 

• Modify and enhance the functionality of the model as needs change in the future. 

• Reuse the model or transition the model to a different SE architecture, such as from 
DIS to HLA, from standalone to HLA, or from HLA to the next SE architecture. 

The third level of architecture is that of the software running within each computer that is used to 
implement, for example, a manned simulator or a SAF. As with the second architecture level, 
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this strongly affects how easy or difficult it is to modify and enhance the functionality of the 
model as needs change in the future. 

4.3.2 Computers 

Driven by demand in the commercial market, there has been a tremendous increase over the past 
fifteen years in all facets of computer technology, from the clock speed and computational power 
to available RAM, to on-line data storage. Microprocessor computational power has doubled 
approximately every 18 months. The cost of RAM has decreased at the same rate. Each time it 
has appeared that there might be a technological barrier or limit, a solution has been found and 
the barrier has been hurdled. No one sees any insurmountable barriers to the continuation of 
these trends. 

The latest Pentium and Merced microprocessors have enormous computer power and huge 
commercial markets. Their present computational power exceeds that of the Sun and Silicon 
Graphics (SGI) workstations of just a few years ago, and at a much lower cost. The Army’s 
M&S activities are minuscule compared to the commercial market and it will be able neither to 
specify, nor to develop, its own computers. The Army’s M&S role is as a user of commercially 
available computers. There are likely significant cost and system development time advantages 
that the Army can gain by being a pro-active follower of computer technology trends and 
transitioning away from higher cost, more difficult to use UNIX workstations, to lower cost, 
easier to use Windows NT personal computers for implementing elements of the synthetic 
environment. 

4.3.3 Display Devices 

Display devices include computer monitors, cathode ray tubes (CRT) of various sizes, large 
screen rear and front projection displays, liquid crystal display (LCD) and active matrix color flat 
panel displays, and helmet mounted displays. Each has its role in displaying information to 
participants in or users of the synthetic environment. The technology for all of these, with the 
exception of some of the militarized helmet mounted displays, is driven entirely by demand in 
the commercial marketplace. The Army’s M&S programs are too small to affect any of these 
developments and again have a role only as a user of commercially available display devices. It 
should take a pro-active role in staying current with the available commercial display devices 
and those under development, so they can be utilized as needed in implementing the SE. 

4.3.4 Display Generators 

It was not too long ago that the market for computer image generators (CIG) was dedicated 
almost entirely to military M&S programs. CIGs were very large and very expensive, semi¬ 
custom devices used for military applications, such as generating out-the-window views in 
aircraft cockpit simulators. Many of those CIGs are still being used in their original systems. 
However, the market for image generators or display generators has been driven for some years 
by the commercial market for computer games. For example, the former GE Daytona, at one 
time a leader in CIGs for aircraft simulators, has now become a commercial spin-off from the 
Lockheed Martin Company. Their two most important products are: 1. A display generator chip 
set and circuit board used in video arcade games and 2. A new display generator chip developed 
for Intel Corporation. By recognizing and taking advantage of the commercial development 
trends, the Army can have the latest technology display generators in its implementation of 
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synthetic environments. This will provide ever increasing computer graphics capability, at low 
acquisition costs. 

The major precaution in using commercial products is that they become obsolete very quickly- 
from six to eighteen months in many cases. To utilize cost effective commercial products, the 
implementation must be highly modular, so that the commercial devices can be easily replaced 
with the latest model. Care must be take to ensure that each implementation is not unduly 
dependent on the peculiarities of a particular device, which can soon become obsolete and 
unavailable. 

4.3.5 Man Machine Interface 

A Man Machine Interface exists to enable the user to better interact with the computer simulation 
operating at the time. This is important, because, as simulations become more complex or have 
more variables to consider, the user must be able to input, change or refine those inputs. Also, a 
man machine interface enables the user to receive input from the simulation. However, care must 
be taken to ensure the training required to use the interface is minimal. 

The interface design should consider three factors. First, it should allow for easy interaction with 
the simulation. This can be accomplished by using open architecture and common operating 
systems. Ideally, the computer simulation should not require any special training for its use. This 
will enable the user to get the maximum benefit from the simulation. Second, the interface 
should be matched to the type of simulation and the requirements. For example, some 
simulations require only voice input. Therefore, only voice commands are needed, not graphical 
inputs. Also, all interactions with the simulation should be through organized systems. This will 
inherently allow for interfacing with command and control systems. The third factor is the 
commercial market. It is believed that the commercial sector will drive the types of interface 
technology developed. Users in the future will be familiar with Sega type games. If the interface 
is designed with that in mind, the technology will be developed by industry for video games. 

This will free simulation dollars to be spent on developing data format structures and other 
algorithms required for the military application. 

As mentioned above, there are types of interfaces that only require a voice interface for 
personnel directly interacting with the simulation. The simulation should be able to recognize a 
multitude of voice commands and respond to those commands. Once again the commercial 
sector has developed this technology and it only needs to be applied. Software, such as Verbex, 
has a vocabulary of several hundred words or phrases. 

By recognizing these latest technologies, the Army can take advantage of the latest 
developments. This will provide a continued increase in capability, if the simulation is 
engineered to allow for the easy replacement of the software or hardware it uses. 

4.3.6 Networks 

As with computers and display devices, this area is driven by the commercial market. The Army 
should take advantage of the developments that will occur. Being pro-active will ensure that the 
network technology used by the Army remains current and supportable. 
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4.3.7 Software 

The software can be conveniently subdivided into five areas for discussion purposes: operating 
systems, application program interfaces (API), applications and models, graphical user 
interfaces, and databases. Of these, the operating systems, most software development,and 
software analysis tools will be COTS products. The rest of the software will be custom, 
semicustom, reused, or modifications of software that already has been developed to meet the 
specific needs of the SE. 

4.3.7.1 Operating Systems 

There are two operating systems of major interest to the synthetic environment: UNIX and 
Windows NT. A version of UNIX is the operating system for most computers currently being 
used in the SE. This is not necessarily due to the superior quality of this operating system, but 
rather because this operating system was provided with the Sun and SGI classes of workstations. 
Workstation class computers have been used in most SE applications, because of the amount 
computer horsepower they have. As was mentioned in Section 3.3.2, the latest Pentium and 
Merced microprocessors have greater computer horsepower than the Suns and SGIs of just a few 
years ago, and they cost much less. For these Intel microprocessors, Windows NT is a superior 
operating system to UNIX. To take advantage of the advances in the commercial arena, the trend 
should be to Pentium and Merced microprocessors as the basis for the computer hardware, and to 
Windows NT as the operating system. 

4.3.7.2 Application Program Interfaces 

The application program interface is what its name implies. It is a layer of software which serves 
as an easy to use interface between the operating system and the application program. It is 
usually language specific, e.g., a set of C++ functions which the C++ application program calls, 
when operating system functions are needed by the application program. There should be a high 
degree of reuse of well designed APIs. 

4.3.7.3 Applications and Models 

The application software and the models will be implemented with custom software. The Army 
will have to write, or pay contractors to write, all of this software. The potential for cost 
avoidance occurs when the applications and models are modular, well designed, and well 
documented. When they are then finding and fixing bugs is much simpler. Also, software 
models can be more easily maintained and upgraded when the underlying entity (e.g., Ml A2 
Abrams) is upgraded. And finally, reuse or reuse with modification is easier across the three 
domains, and across multiple programs. 

4.3.7.4 Graphical User Interface 

The tools for designing, prototyping, and building graphical user interfaces (GUI) are COTS 
products. The GUIs themselves are custom designs. The intuitiveness of the GUI facilitates 
learning new applications easily. It is the power behind the GUI that makes it fast and efficient 
for performing the operations needed to define, set up, and operate the SE and for selecting and 
analyzing data. 

The Army’s functions relative to GUIs are primarily as specifiers, design overseers, and end 
users. They should be intimately involved in: 
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• Preparing the specifications for GUIs that will be used by Army personnel and Army 
contractors. 

• Assuring that the Army’s usability objectives are being met through participation in the 
detailed design reviews of GUIs. 

• Assuring that the designs and documentation are complete and robust through careful 
specification and review of user documentation, including on-line help documentation. 

• Assuring that the documentation is easy to understand and facilitates learning to use the 
system effectively and efficiently. 

4.3.7.5 Databases 

There are four key aspects of databases. First is the structure of the database. The structure 
determines what kinds of data can be stored, how that data is stored, how much data can be 
stored on a particular device, and what processes can be used for storing and retrieving data. 
Second is the process or processes used to prepare the data and store it in the database. Third is 
the process of retrieving data from the database. Fourth is the actual content of the database: the 
data that is prepared, stored, and later retrieved. Databases are powerful and flexible concepts 
and, when well thought out and properly implemented, can greatly simplify the building and 
modifying of models and simulations. The deliberate definition and use of common databases 
can facilitate the reuse and integration of models across multiple applications within the three 
M&S domains. As part of the process of developing databases, it is equally important to develop 
software which can accept the raw data in its various formats and quickly prepare it and load it in 
the appropriate databases. Provisions must also be made for verifying the database contents and 
for assuring its integrity. 

4.3.8 Tools 

The purpose of a tool is to help perform an activity easier, faster, cheaper, and/or better. 

Effective tools can save large amounts of effort and can significantly reduce costs. There are 
many tools which have been and are being used to design, develop, set up, operate, and maintain 
various aspects of the SE. There are general-purpose COTS tools, such as editors, language 
compilers, linkers, loaders, and symbolic debuggers. There are COTS tools to support building 
and maintaining libraries and for configuration management. As mentioned previously, there are 
COTS tools for building GUIs. For the most part, the other tools that will be needed will be 
custom tools developed with Army funds, or reused from tools developed by the other services. 
This means that the Army should try to assure that their programs develop good tools and 
document them well. Whenever possible, the tools should try to have broader application than 
just the program at hand. It also means that there should be a focal point within each service with 
knowledge of a repository of available tools and documentation, to facilitate reuse and minimize 
duplication of effort. 
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5. SUMMARY OF EXECUTION PLANS 

5.1 STRICOM Business Environment 

In this section we summarize the execution plans that address both the enabling technologies and 
the synthetic environment issues that were identified during the interviews. The SE issues were 
discussed in Section 4.2. The enabling technologies were discussed in Section 4.3. 

Since viable execution plans must be compatible with the business environment in which 
STRICOM operates, we begin by examining that business environment. There is a colloquial 
motto which states, “The Golden Rule: He who has the gold makes the rules.” Although cynical, 
this motto captures the essence of business operations. This relates to the synthetic environment, 
because there is a mismatch between the way programs are funded and controlled and the overall 
needs of the SE. 

There is much that can be done to improve the synthetic environment that would benefit both 
those who pay for developing the SE and the end users of the SE capabilities. These benefits 
include easier setup and control of experiments and tests, better interoperability and 
reconfigurability, better data collection, and better analysis tools. They could also include lower 
combined development, operation, and maintenance (life cycle) costs. Achieving these 
improvements could be facilitated by doing a better job of defining requirements, developing 
architectures and interfaces, developing and conforming to M&S standards, designing for ease of 
use, and designing with modularity and reuse as objectives. These things are achievable over 
time, through appropriate coordination, cooperation, and shared visions within the Army and 
across the Services and programs. However, money is a key driving function in this process. 
There needs to be a willingness and incentive on the part of those with the funds to invest in 
these objectives and visions. 

In project driven environments, such as STRICOM's, most of the funds are provided to and 
controlled by the program managers. With few exceptions, program managers are tightly focused 
on their individual programs. Therefore, in such an environment, it is necessary for STRICOM to 
exercise the vision needed to coordinate investment from existing programs toward the future, 
the core infrastructure capabilities, and an improved SE. Recognizing that benefits were gained 
from earlier programs, STRICOM needs to continue to make investments that will benefit both 
current programs and others in the future and to create incentives for program managers to 
contribute to such efforts. Such coordinated investments are needed, because the development 
costs are beyond the scope of any one program. 

By teaming with other programs, investment resources (personnel and funds) will be maximized, 
thus creating a more robust synthetic environment. This requires cooperation across three 
perspectives of the SE. These three perspectives are: operational, systems, and technical. 

5.1.1 Operational Perspective 

The operational view was defined as that of users of the synthetic environments. These include 
commanders of forces at various echelons, the staffs who provide information to them, 
researchers, analysts, instructors, and trainers. They are concerned about which aspects of the 
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operational forces can and cannot be represented. Of those aspects represented, they are 
concerned about how well they can be represented. The Army subdivides the operational 
viewpoint into three M&S domains: ACR, RDA, and TEMO. The needs for SE capabilities 
come primarily from people and organizations within these three domains. The funding to 
develop and provide the synthetic environment should therefore come from these domains. 
STRICOM's role would be to actively solicit funds from the M&S domains, and to help facilitate 
other organizations in program development. STRICOM's goal would be to oversee the SE and 
provide solutions to others' M&S needs. In that role, they should work to combine needs from 
multiple sources and develop common technical solutions. The result would be lower overall 
costs to the organizations involved than if the efforts were stand-alone and uncoordinated, by 
cost avoidance through synergy and reduction of duplication by programs. It would also be an 
avenue to improving the SE. 

5.1.2 Systems or Program Perspective 

The second view is the systems or program perspective, which is that of the program managers 
who are responsible for particular programs. They view their system as a task which they must 
accomplish. These are the people who have and control the funds. As senior career officers, their 
performance evaluation is based on completing their program within the confines of its 
requirements, schedule, and funding. Currently, investing in the SE may even conflict with the 
pressures on program managers to conserve their funds to allow for unforeseen occurrences. 

STRICOM’s value added role should be twofold: 1. to create incentives for program managers to 
invest in the SE common capabilities and recognize how this change may impact on their 
ultimate performance; 2. for development of common capabilities, find a way to generate, 
conserve, or allocate the working capital and investment capital which are beyond the means of 
the programs to contribute. To gain cooperation from the program managers, STRICOM also 
needs to become an entrepreneur and an investor, looking for opportunities to provide cost 
avoidance to programs by developing and selling SE common capabilities. To do this, 

STRICOM needs a valid vision of the common capabilities which are marketable to programs. 
This report addresses the identified issues and plans for implementation. Although we believe 
there is a need for STRICOM to evolve toward a new business approach, we have not attempted 
to develop a corresponding strategic business plan. 

5.1.3 Technical Perspective 

The technical perspective is that of the Army and contractor engineers who are tasked with 
implementing and integrating the pieces which comprise either a particular system or the SE as a 
whole. This is the level at which we have prepared the individual strategic environment 
execution plans presented in this report. These plans address how to utilize the enabling 
technologies, and how to develop technical solutions to the identified SE issues. 

5.2 Overall Strategy 

The overall strategy for STRICOM to improve the synthetic environment has three aspects: 

• Funds 

• Organization 

• Contractual 
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5.2.1 Funds 

It may seem too obvious to need stating, but funds are absolutely necessary to accomplish 
anything. Both STRICOM and its contractors must be funded to perform the tasks needed to 
maintain and improve the SE capabilities and infrastructure. As was discussed in Section 5.1, the 
current funding environment places control of the vast majority of the funds in the hands of the 
PMs. Central funding of the SE is small and declining. STRICOM needs to develop a business 
strategy to raise discretionary working capital and investment capital with which to address SE 
issues in a more centralized way on behalf of the Army. 

Another way to provide funding to improve the SE is to develop strategic alliances with 
TRADOC, the Program Managers, the Program Executive Offices, and the other major 
commands and organizations within the Army Materiel Command. 

5.2.2 Organization 

Implementing the recommendations for how to best make use of the enabling technologies 
requires two things: 

• Access to technical experts who understand how to cost effectively apply the enabling 
technologies within and across programs. This expertise can reside with STRICOM, its 
contractors, other Government organizations, or across a combination of these. 

• A technical manager or group of managers with the desire, ability, and the authority to 
take analyses and recommendations from the technical experts, consider the impact 
within and across programs, and make enforceable decisions relative to utilizing 
enabling technologies in the programs. 

Similarly, addressing the identified issues and achieving synergy in solving them requires two 
things: 


• Access to technical experts who understand how to cost effectively implement 
solutions to these issues. This can be a combination of STRICOM engineers, contractor 
engineers, and the Government engineers. 

• A technical manager or group of managers with the desire, ability, and authority to take 
analyses and recommendations from the technical experts, consider the impact within 
and across programs, and make enforceable decisions about implementing solutions in 
the programs. 

Putting these organizational recommendations into effect is needed to truly address and 
implement solutions to the identified SE issues. 

5.2.3 Contractual 

Consider those programs for which STRICOM is the contracting intermediary between other 
Army or Government organizations and defense contractors. A different pricing strategy by 
STRICOM towards the funding agency, pricing based more on “value to the agency,” than on 
simply “cost plus loading,” could be a step toward “earning a profit” which could be used to 
establish and build up working capital and investment capital. 
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Consider the contracts that STRICOM issues to defense contractors. For the research and 
development types of programs, a cost Plus Award Fee (CPAF) type of contract provides 
STRICOM and the agencies providing the funding with the maximum leverage to enforce proper 
use of the enabling technologies and designs and implementations which help solve the 
identified SE issues. To ensure fairness to their contractors when using CPAF contracts, there 
must be realistic evaluation criteria. Since research and development work by nature has a level 
of performance uncertainty, a distinction must be made between slow progress, because the task 
is difficult, and under-performance by the contractor. 

In summary, the overall strategy to improve the SE involves: 

• Acquiring discretionary working capital and investment capital 

• An organizational structure which fosters enforcement of good SE design and 
implementation decisions 

• Contractual policies which support this strategy. 

5.3 Evaluating the Choices 

This report summarizes and prioritizes the SE issues which were identified by the interviewees. 

It also identifies the key enabling technologies which can facilitate addressing the SE issues. The 
questions addressed by this subsection are: 

• How does one decide which issues to address? 

• How does one allocate the available funding among those issues? 

In approximate priority order, there are seven key factors that must be traded off in trying to 
answer these questions. An initial assessment of high, medium, or low is required in each 
instance where H,M,L appear. 

• What is the priority assigned by higher level commanders to solving the issue 
(H,M,L)? 

• What is the profile of the discretionary funding? 

• What is the potential benefit of each solutions (H, M, L)? 

• When is each solution is needed? 

• What is the estimated development cost and profile? 

• What is the profile of available funds dedicated to the specific issue? 

• What is the development risk (funding, schedule and technical) for each issue 
(H,M,L)? 

The ideal issues to address first are those that have a high priority assigned, high potential 
benefits, low development risk, are needed relatively soon, and whose development cost profile 
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is satisfied by dedicated funding. The issues to address last are those that have a low priority 
assigned, low potential benefits, high development risk, are not needed soon, and have 
insufficient funding available. Most issues fall somewhere between these two extremes. 

An initial priority order for addressing issues can be arrived at by 

• Assigning a weighting to each of the factors (e.g., 1 to 5) 

• Rating each issue against each factor (e.g., 1 to 5) 

• Computing a composite weight for each issue as the sum of the products of the 
weighting factors and the rating. 

This is not an exact process, but it is a straight-forward way to apply a perspective to the issues 
being addressed. The final priority order should be a management decision, made after 
consulting with the affected programs and the technical experts. 

5.4 Enabling Technologies Execution Plans 

This section presents recommended courses of action for STRICOM for each of the eight 
enabling technologies: architectures, computers, display devices, display generators, man 
machine interfaces, networks, software, and tools. 

5.4.1 Architectures 

In Section 4.3.1 architectures at three levels were discussed: the architecture of the overall SE; 
the architectures of the CGFs, SAFs, manned simulators, and the C4I; and the architecture of the 
software running within each computer. 

5.4.1.1 Overall SE Architectures 

A standard architecture for the SE is a prerequisite for being able to develop systems that can 
interoperate in a distributed environment. There are at least four such architectures that are 
important: SIMNET, DIS, ALSP, and HLA. SIMNET was the first widely used architecture, 
with its associated interface, protocol, and data format standards. This was followed by DIS and 
ALSP. There are many existing SIMNET-compatible simulators in use today. There are also 
many DIS-compatible simulators in existence, and others under development. DIS is now an 
IEEE standard. There are some ALSP simulations in existence, but a smaller number than for 
DIS. The newest architecture for the overall SE is HLA. DMSO has been funding and promoting 
the HLA. Everyone who is involved with DoD M&S is aware of the DoD’s HLA Mandate. 

What should STRICOM’s role be? First, it should have an active involvement in the Architecture 
Management Group (AMG) and the Architecture Standards Coordinating Committee, to 
participate in the definition and standardization of architecture for the SE. Second, it should have 
in-house or have access to engineers with expertise in HLA, HLA tools and HLA applications to 
new systems and to legacy systems. Third, it should ensure that the current systems that it is 
developing are compatible with the appropriate SE architecture (DIS and HLA). Fourth, it should 
be pro-active in retrofitting its legacy systems (and other's systems) with HLA compatibility. 

This could also include R&D to develop interface adapters which could be tailored to a number 
of different legacy systems. 
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5.4.1.2 Architectures of CGFs, SAFs, and Manned Simulators 

Many of the CGFs, SAFs and manned simulators under development now or in the future, are or 
will be funded through STRICOM. Examples are WARSIM 2000, OneSAF, and CCTT. 
STRICOM needs to have in-house or access to (through contractors and other Government 
agencies) systems engineers with architectural experience and expertise, to ensure that the top 
level architecture of each system is appropriately modular, meets appropriate M&S standards, 
will be interoperable via HLA, and can be maintained and upgraded in the future. 

5.4.1.3 Software Architectures 

This is one step more detailed than the system architecture which was just discussed. There is 
much that can be done by software engineers to develop software with good overall designs, 
appropriate modularity, and that can be maintained and upgraded in the future. STRICOM needs 
to actively participate in the design reviews of its projects, especially at the software architecture 
and software design levels, to ensure that these objectives are being achieved. 

5.4.2 Computers 

Army M&S is a user of computers. The commercial market drives the development of 
computers. STRICOM should carefully track what is happening in the commercial computer 
market, and try to use mainstream computers, e.g., Pentium microprocessors, to the maximum 
extent possible in its projects. This requires having in-house, or readily accessible, persons to 
perform this tracking function and to be involved in STRICOM projects when decisions are 
being made about what computers to use. 

5.4.3 Display Devices 

As with computers, Army M&S is a user of devices which are developed by the commercial 
market. STRICOM should track the commercial market and ensure what is proposed for use in 
its projects makes technical and economic sense. New devices may open up possibilities for 
improving the SE. 

5.4.4 Display Generators 

The comments in Section 5.4.3 also apply here. 

5.4.5 Man Machine Interfaces 

The key in this area is to recognize the latest technologies as they are developed. The Army 
should not be in the business of developing this technology, but should use and adapt the 
technology for their needs. This is similar to the sections above, where the commercial market 
will drive the technology and the Army applies the technology. However, unlike computers, 
which are purchased and used as sold, some special applications may have to be developed to 
ensure optimal use of the product for the simulation. 

5.4.6 Networks 

The comments in Section 5.4.3 also apply here. 
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5.4.7 Software 

The discussion of software in Section 4.3.7 addressed five areas: operating systems, applications 
program interfaces, applications and models, graphical user interfaces, and databases. Comments 
on these areas follow. 

5.4.7.1 Operating Systems 

Operating systems are COTS products. The comments relative to computers in Section 5.4.2 
apply also to computer operating systems, i.e., go with the mainstream flow in the commercial 
market. 

5.4.7.2 Application Program Interfaces 

Net cost avoidance across STRICOM’s programs comes from designing APIs for reuse. This 
impacts the first program to do it, but there are accumulated savings when other programs reuse 
the APIs, probably with minor modifications. STRICOM’s role should be to ensure the original 
development of reusable APIs, and then foster their use on subsequent programs. 

5.4.7.3 Applications and Models 

STRICOM can achieve life cycle cost savings within each of its programs by ensuring that 
software is well designed, well tested at appropriate levels in its development, and well 
documented. This involves having the appropriate level of technical experts and oversight 
involved in the specification, design, and development of the software for its programs. 
Accumulating additional cost avoidance across programs can occur by sharing concepts, designs, 
and code among programs. This requires having some people who work across program 
boundaries, rather than having each individual dedicated to a specific program. 

5.4.7.4 Graphical User Interfaces 

Having common standards, which are as close as possible to commercial GUI standards, will 
help make GUIs more intuitive, easier to learn, and easier to use. This will also reduce the 
training time required for users who know one simulation to learn another simulation. 
STRICOM’s role should be to try to achieve, to the extent that it makes sense, a common look 
and feel to the GUIs of its simulations. 

5.4.7.5 Databases 

As mentioned in Section 4.3.7.5, there are four key aspects of databases: the structure, the 
process of preparing raw data and storing it, the process of retrieving the stored data, and the 
stored data itself. Databases are used for storing data which can be represented in tabular or 
matrix form. For smaller tables and matrices where access is by indexing, standard software 
constructs, such as simple arrays and arrays of structures, will probably suffice. Most modem 
computer languages support these. For databases from which information is accessed by non- 
real-time queries, COTS databases probably suffice. For databases that do not fit these 
parameters, it is likely that custom databases will be needed. Probably the most well known 
example of this is the terrain database. The issues related to terrain databases were raised in 
Section 4.2.1 and discussed further in Section 5.5.1. 

The process for designing application specific databases is done by engineers who are 
developing specific systems. Cost avoidance occurs when an existing database stmcture (with its 
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processes for preparing, storing, and retrieving data) can be reused, or reused with minor 
modifications, from a previous system. Further cost avoidance occurs when database contents 
can be reused, or reused with reformatting, from an existing database. The efforts at 
standardizing databases are intended to facilitate this reuse with its subsequent cost avoidance 
and schedule advantages. 

STRICOM’s role relative to SNE databases is discussed in Section 5.5.1. For STRICOM’s 
programs, they should review the proposed database designs and, where appropriate, channel 
them toward reusing existing databases and their contents. 

5.4.8 Tools 

There are two broad application areas for tools for the SE.. The first is tools that are used in the 
design, development, set-up, and analysis of a simulation. This use of tools is primarily for the 
developer and the simulation user. The second use of tools is for the program manager. In this 
case, the tool set is used in the management of simulation programs. 

STRICOM’s role would be to identify the areas where tools could be of benefit for the 
developer, the user, and the program manager. After those areas are identified, the tools for a tool 
set would be developed. This would help in the execution of current simulations. It would also 
help the development and management of new simulation programs. 

As with computers, display devices, and display generators, STRICOM should carefully track 
what is happening in the commercial market. Many software companies are developing 
applicable tool sets. STRICOM should try to use, and encourage its contractors to use, COTS 
tools to the maximum extent possible. The strategy for developing custom tools is discussed in 
Section 5.5.7. 

5.5 Identified Issues Execution Plans 

This section describes recommended courses of action for each of the seven categories of issues 
discussed in Section 4.2: SNE, representation of behaviors, interoperability, reconfigurability, 
C4I, numbers of entities, and tools. 

5.5.1 Synthetic Natural Environment 

There is considerable work that needs to be accomplished in this area. All of the models in 
Figure 3 SNE Interactions can use extension and, in some cases, development. There needs to be 
an authoritative representation of the natural environment and a common technical framework. 

The authoritative representation of the natural environment can be described as models of 
operations. Those models depend on interaction with representations of the natural environment. 
This includes interaction with permanent and semi-permanent man-made features, realistic 
representations of weapons effects, and the resulting environment. To accomplish this requires 
four-dimensional (the fourth dimension is time) terrain, ocean, atmosphere, and space 
environmental models. When developing these models, they must be seamless to present a fully 
integrated data set for M&S use. 
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The terrain representation includes configuration, composition, and representation of the surface 
of the earth. Also included in the terrain is the variation that occurs with the seasons, (e.g., grass 
and snow cover, leaves and barren trees, shadows and sun). 

For the ocean representation, features such as ocean bottom, whether natural or man-made, must 
be considered. Other characteristics to be considered include temperature, pressure, salinity and 
acoustic phenomena. 

The atmospheric representations must be developed from the earth’s surface to space. In addition 
to the standard atmospheric domain, particle and aerosol effects must be included. This also 
includes nuclear, biological, and chemical effects. Other traditional weather parameters, like fog, 
clouds, precipitation, temperature, pressure, and winds, must also be considered. 

The space representations are needed for the processes that affect satellite, spacecraft, and 
missile performance. Some of these conditions are natural in origin, such as a solar flare. Others 
are man-made. In either case, changes in the geomagnetic field and charged particles must be 
accurately portrayed. 

To address model and data inter-usage needs, most respondents stated a need to continue the 
development of HLA and SEDRIS. Both of these were looked at as means to efficiently and 
effectively share resources. HLA compliance would allow individual models to federate and 
become part of a larger simulation. By using a common data interchange format, SEDRIS, the 
long-standing proprietary databases that have been developed would be useful for more than one 
program. Any new databases and the subsequent simulations would develop Application 
Program Interfaces (APIs) to allow for the easy interchange of data in the SEDRIS format. These 
two efforts would allow reuse and enable greater cost avoidance in the future. 

Another outcome of developing higher fidelity models that use a common format, is consistency 
among simulations. Similar models, if not the same ones, could be used both in the training 
environment and for mission rehearsal. 

STRICOM’s role should be in three areas. First, fund the development of higher fidelity models. 
Next, continue to support HLA integration and compliance. Finally, make SEDRIS the 
interchange standard and ensure SEDRIS matures to meet the increasing needs of the M&S 
community. 

5.5.2 Representation of Behaviors 

Of the seven categories of issues that were identified in the interviews, the representation of 
behaviors is a category which is truly a research topic, and will require a research approach. The 
other categories of issues are, for the most part, amenable to engineering solutions. A research 
approach means that the answers are not known, and it will take technological or intellectual 
breakthroughs to find workable answers. For engineering solutions, on the other hand, the 
answers are usually known, the problems to be solved to attain those answers are usually easily 
identified, and reasonable plans of attack are usually readily defined and followed to implement 
the answers. The strategy here would be to solicit and fund a variety of promising, but usually 
high risk, ideas. 
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By dissecting the problem into smaller pieces and attacking those pieces, some specific solutions 
can be found more quickly than by seeking a general solution to the entire problem area. For 
example, we can divide Army operations into three classes of scenarios: 

• Open Battlefields, 

• Urban Warfare, and 

• Support and Security Operations (formerly Operations Other Than War) 

Subdividing the solution leads to the following: 

• Descriptions of Behaviors (e.g., word descriptions, such as a psychologist or 
sociologist might use; doctrinal behaviors, as described in Army manuals; doctrinal 
behavior, as described in joint, coalition, or opposing forces (OPFOR) manuals; 
descriptions of cultures, etc.). 

• Frameworks for Representing Behaviors (i.e., conceptual structures which (1) can be 
used to represent a class or classes of behaviors, and (2) are amenable to processing by 
computer programs). 

• Representations of Behaviors within the Frameworks (i.e., populating frameworks with 
appropriate data which represents specific behaviors). 

The logical place to begin is the open battlefield scenarios, which is the focus of current SAFs 
and CGFs. Assemble documentation on the available training and fighting doctrines for each 
echelon of forces, starting from the individual soldier and working up to platoons, companies, 
brigades, etc. Keep the viewpoint as modular as possible, by defining non-overlapping entity 
types within each echelon. Examples of entities at the individual soldier level are tank driver, 
gunner, and tank commander. Examples of entities at a group with vehicle level are tank with 
crew, armored personnel carrier with crew, and helicopter with crew. 

Now choose an easy example, such as ground vehicles, and choose a type, like a refueling truck. 
Next find an astute operations person who knows the doctrine and has experience in the 
environment. Team him or her with a creative modeler and an experienced software engineer. 
The assignment for this team would be to develop the best framework they can for describing the 
behaviors, as functions of the battlefield environment. Next have them populate the framework 
with the behavioral data. This is an iterative process. When this simple vehicle has been done 
satisfactorily, repeat for another type of vehicle, working from what is seemingly the easiest 
toward the most difficult. Continue as long as good progress is being made. 

Repeat (perhaps in a parallel or overlapping fashion) for other classes of entities, such as fighting 
vehicles with crews, squadron commanders, company commanders, etc. Start with what seems to 
be the easiest and work toward the most difficult type of behavior. 

Each time a team stops because the problem is too difficult, there is a need for research to find a 
solution. The research effort and funding should probably be focused simultaneously in two 
directions: (1) toward lower difficulty (lower risk) problems whose solutions would provide a 
reasonable to high return on funds invested, and (2) toward high difficulty (higher risk) problems 
whose breakthroughs would significantly improve M&S capabilities. 
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5.5.3 Interoperability 

Conducting distributed simulations presupposes that the components of the simulation can 
interoperate. That is, they can communicate (send and receive data and interact with appropriate 
time synchronization) information, such as position, orientation, velocity, sensor detections, 
weapons firings, etc. (Radio communications between players is discussed in Section 5.5.5 C4I). 

Referring to Figure 1, we can readily imagine that achieving interoperability requires 
compatibility on several levels. The first level is the ability to successfully send and receive data 
via the Interconnections function. This requires signal level compatibility, easily achieved using 
COTS LANs, WANs, modems, etc. It also requires protocol compatibility, also easily achieved 
using COTS network software. 

The second level of compatibility is the data structure and format of the messages which are sent 
and received. All participants in the simulation must understand and be able to encode into and 
decode from the permissible message formats. 

The third level of compatibility is to understand the meanings of messages received. 
Interoperability is never achieved accidentally or through good fortune. It is only achieved by 
deliberate actions. These actions generally fit into one of three strategies: designing for 
interoperability (by agreeing a priori on protocols and formats); inserting (perhaps preceded by 
developing) translators (gateways) between dissimilar protocols, formats and/or systems; and 
retrofitting interoperability capabilities into previously non-interoperable systems. Currently, 
there is active work going on within all three of these strategies. 

5.5.3.1 Designing For Interoperability 

Earlier examples of this are simulators that were designed to interoperate via the SIMNET, 
simulators and simulations designed to interoperate via the DIS, and simulations designed to 
interoperate via the ALSP. Current examples include simulators and simulations being built to be 
DIS compatible, and simulators and simulations being designed or built to be HLA compatible. 

5.5.3.2 Inserting Translators 

One example of this is the Operational State Interpreter (OPSIN) that performs aggregation, de¬ 
aggregation, and message translation between Brigade/Battalion Battle Simulation (BBS) and 
ModSAF. Another is a gateway that performs protocol translation between a DIS simulator and 
an HLA network. 

5.5.3.3 Retrofitting Interoperability Capabilities 

Earlier examples of this are stand-alone simulations that were retrofitted with DIS capabilities. 
Current examples are simulators and simulations that are being, or are planned to be, retrofitted 
to be HLA compatible. 

This area of interoperability falls into the domain of engineering (and economical) solutions. It is 
entirely achievable, however, achieving interoperability for any particular simulator or 
simulation may or may not be economically attractive. 


39 

Use or disclosure of information on this page is subject to the restrictions referenced on cover of this report. 

UNCLASSIFIED 




ADST-II-CDRL-SESP-9800192 

7/15/98 

STRICOM should take a major leadership role: (1) as a developer of methods and tools for 
designing to HLA standards, (2) as a developer of HLA translators for existing systems, (3) as a 
developer of methods and tools for retrofitting HLA into existing systems, (4) as a focal point for 
overseeing new designs for HLA compatibility, (5) as a focal point for assisting in incorporating 
translators into existing systems and (6) as a focal point for overseeing and contracting (on 
behalf of others) for retrofitting HLA into existing systems. 

This requires up-front funding for development of tools, methods and translators. It requires 
technical expertise in architectures, standards, systems engineering, hardware, and software on 
the part of STRICOM engineers, its contractors, or a combination of both. It also requires a focus 
on selling STRICOM and its contractors to the funding sources as value added providers who 
can do the job cheaper, faster, and better than if the others try to do it themselves or with their 
contractors. 

5.5.3.4 Terrain 

One other major aspect of achieving interoperability relates to the terrain database. There must 
be a correlation in elevation between the terrain representations, or else ground vehicles may 
appear to float in the sky, be out of view below the ground, or have different intervisibilities 
(vehicle A can see Vehicle B, but not vice versa). The latter prevents conducting a fair fight. The 
former prevents effective gunnery. 

Lack of terrain elevation correlation between visual systems and C4I systems results in cases 
where two vehicles are mutually visible, but can’t communicate in the simulator with line of 
sight radios, or where two vehicles are not mutually visible, but can communicate in the 
simulation with line of sight radios. Neither case is correct. 

These simulation anomalies due to uncorrelated terrain elevation representations have 
engineering solutions. Actually implementing the solutions is primarily a funding issue. It may 
be very costly to change the terrain representations in the affected simulators, simulations, and 
radios. 

5.5.3.5 M&S Interchange Format 

A major step toward achieving interoperability between systems, simulators, and simulations 
would be to have a common data interchange format. STRICOM has already invested significant 
resources into developing SEDRIS for this purpose. Using SEDRIS as the data interchange 
format can facilitate interoperability, because both the producer and the consumer of data can 
develop standard APIs for inputting and outputting data in the SEDRIS format. Over the long 
term, this will facilitate reuse of data. It will also help to steer the M&S community away from 
proprietary solutions and unique databases. 

5.5.4 Reconfigurability 

The comments in this category related to two aspects of reconfigurability: 

• Multipurpose simulators, and 

• Reprogrammable simulators 
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5.5.4.1 Multipurpose Simulators 

The main reason for wanting multipurpose simulators is to reduce the acquisition and 
maintenance costs of having different simulators for different purposes. Suppose there is a need 
for 50 Ml A2 tank driver simulators for training purposes on day one, 50 Ml A1 gunnery 
simulators on day two, 50 M2A2 driver simulators on day three, and 50 M2A2 gunnery 
simulators on day four. This could come from training needs or to conduct an experiment. The 
acquisition cost question is this: should the Army develop and procure 200 individual task 
trainers (50 M1A2 drivers, 50 M1A2 gunnery, 50 M2A2 driver, and 50 M2A2 gunnery), 100 
Option #1 multiple task trainers (50 Ml A2 dual task trainers and 50 M2A2 dual task trainers), 
100 Option #2 multiple task trainers (50 reconfigurable driver trainers and 50 reconfigurable 
gunnery trainers), or 50 fully reconfigurable trainers that can be configured for any of the four 
tasks? In other words, is it more economical to acquire and maintain 200 individual task trainers, 
100 dual task trainers, or 50 multitask trainers? The answer depends on the degree to which the 
simulator should replicate the look and feel of the vehicle. An earlier generation of soldiers 
probably preferred a simulator that replicated the look and feel of the actual vehicle. The current 
generation and upcoming generations of soldiers grew up playing video games. They do not need 
to walk into a simulator to be trained. The current generations can suspend belief in front of a 
video screen and shoot aliens first, drive a motorcycle next, fly an F-16, and then fight a Kung- 
Fu opponent. For them, functionality is important, and the look and feel of the controls is a non¬ 
issue. For the current and for upcoming generations of soldiers, reconfigurable simulators are 
highly feasible. 

A major impediment to developing multipurpose simulators is the way they are funded. Suppose 
it is desirable to have a multivehicle driver training simulator that supports Bradley A3, 

Crusader, and Grizzly. To be fair to each program, they should all contribute to the common 
development. Since the Bradley A3 vehicle is much further along in its development, it has a 
need for simulators well before Crusader or Grizzly. We can make the reasonable assumption 
that a multipurpose simulator, designed for reconfigurability, will cost somewhat more and take 
somewhat longer to develop and field than a single-purpose simulator. Where does the extra 
funding and the extra schedule time come from? The extra schedule time has to be factored into 
the Bradley program. The extra funding should come from Crusader and Grizzly. Ideally the 
three PMs should work cooperatively on developing the simulator. A role for STRICOM would 
be to broker the deal and be the lead in developing the simulator. It has been this type of 
unresolved scheduling and funding issues that have contributed to the current situation of so 
many stovepipe simulators. 

5.5.4.2 Reprogrammable Simulators 

The second aspect of reconfigurability is reprogrammable simulators: that is simulators whose 
software is easily modified. This is important for two reasons. First, the simulator models a real 
vehicle and when the real vehicle’s characteristics are modified or upgraded, the simulator 
should be modified to reflect the new properties. Second, the Army, particularly the ACR 
domain, investigates the effects of adding new capabilities to vehicles. There is the need to 
simulate these proposed capabilities and investigate their effects on the outcome of various 
scenarios and missions. 
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Achieving reprogrammability is an engineering solution. It is achievable through modular 
software design. Designing for reprogrammability takes longer and initially costs more. It also 
requires more documentation of the design, the implementation, and the software development 
tools. Although the likely result is lower life cycle costs through easier software maintenance, 
achieving easy reprogrammability requires more upfront expenditures and a longer initial 
development time. Since program managers have always focused on reducing development costs 
and schedule time for their particular program, it will be necessary to find incentives to have 
them give equal focus to life cycle cost and reusability. 

5.5.5 C4I 

Two categories of issues were identified relative to C4I: 

• Representation of communication networks, bandwidth, and loading, and 

• Integration of C4I systems with the SE. 

5.5.5.1 Representation of Communications Networks 

The division of labor for this is very straightforward. Since the U.S. Army Communications and 
Electronics Command (CECOM) has the knowledge of and responsibility for Army operational 
communication systems, CECOM should have the responsibility for modeling the 
communications systems. Since STRICOM has the knowledge of and responsibility for the 
simulations, STRICOM should have the responsibility for taking those models and implementing 
them in the simulations. For the maximum benefit of everyone involved (CECOM, STRICOM, 
the budget, and the M&S end users) this should be a cooperative effort. By working together on 
STRICOM’s model needs, CECOM can better deliver what is needed without expending money, 
effort, and time in developing unnecessary capabilities or resolution. Furthermore, collaboration 
can result in user interfaces which are more intuitive and easier to use. 

STRICOM should also work with CECOM to develop models that more easily interface into the 
various simulators and simulations. STRICOM’s role would be implementing these models into 
the simulators and simulations. 

Good planning and cooperation between CECOM and STRICOM would reduce the number of 
unique models needed, reduce the number of unique interfaces needed, increase the commonality 
and reuse of software components in the models and interfaces, and result in more nearly optimal 
functionality, while reducing total development costs and life cycle costs for the models and their 
interfaces. 
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5.5.5.2 Integration of C4I Systems with the SE 

Lets begin by discussing two systems communicating with each other as shown in Figure 5. We 
are assuming a bi-directional communication path. This is the general case of two unidirectional 
communication paths (one from A to B, the other from B to A). The two interfaces are 
specifically indicated to aid this discussion. 
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System A 

A 
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System B 
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Figure 5. Two Systems Communicating 

For System A to send a message to System B, it first prepares the message and encodes it in a 
predetermined format. The message is transferred to Interface A, which uses a predetermined 
protocol to put the message onto the communication path (radio link, point-to-point wiring, 
commercial telephone circuit, etc.). The protocol must be such that Interface B can detect the 
presence of an incoming message and know to capture it, as well as, how to capture it. Interface 
B alerts System B that it has received a message and, upon request, can transfer that message to 
System B. Once requested and received, System B decodes the message, perhaps interprets it, 
and can act upon the message. Based on knowing the predetermined format, System B can then 
send a reply or response message to System A in the same manner. 

The above series of operations is very straightforward if: 

• System A and System B understand and adhere to an agreed upon message format 

• System A is compatible with Interface A, and System B is compatible with Interface 
B 

• Interface A and Interface B understand and adhere to an agreed upon communications 
protocol 

• Interface A and Interface B and their protocols are compatible with the Communication 
Path. 

These four conditions must be met by the designs of any two systems that intend to 
communicate. This is always achievable when the two systems are identical. However, a major 
problem occurs when trying to interface C4I systems to models and simulations that were not 
designed to communicate with each other. Currently, no one intends to redesign or modify 
existing C4I systems to make them compatible with simulations. Also, no one intends to modify 
existing C4I systems to make them easier to interface with simulations. Finally, it is unlikely that 
C4I systems being designed now will do this either. Therefore, the full burden of developing 
ways for C4I to interoperate with simulations in the SE has fallen upon those responsible for 
building the SE. 
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The general solution for getting two dissimilar systems to communicate is shown in Figure 6, 
where an Adapter Unit (AU) is placed between the two systems. System A communicates with 
the Adapter Unit using System A's message communication format and protocol. The AU 
translates the message into System B’s format and sends it to System B using the System B 
protocol. 



Figure 6. Adapter Unit Interfaces Between Dissimilar Systems 


System B sends messages to System A in a similar manner, with the AU translating the message 
from System B’s format to System A’s format. The degree of difficulty for developing this AU 
depends on the similarity of the System A and B message formats and contents, and on the 
specific interfaces that Systems A and B use. 

Many unique adapter units have been prototyped to interface a specific C4I system to a specific 
simulator or simulation. Some have been bi-directional; others have been uni-directional. There 
have been efforts to develop a more general adapter unit which could interface to a number of 
systems. One example is the Modular Reconfigurable C4I Interface (MRCI), whose objective 
was to interface a number of different C4I systems to the HLA Run Time Infrastructure (RTI). 
Referring to the AU in Figure 6, the Interface B is the HLA RTI and System A is the target C4I 
system. MRCI’s design strategy was to have interchangeable versions of Interface A, and 
tailorable software modules in the translator. This is a valid strategy. The implementation of an 
adapter unit may not be fully achievable without some modification to System A’s message 
format and contents. Such modifications may be needed, for example, to provide additional data 
needed by System B, or to better allow System B to distinguish between System A message 
types. Since the operational C4I systems are unlikely to be changed to accommodate this, an 
adapter unit’s functionality may be limited to a subset of the full message set. 

Another strategy for interfacing multiple, dissimilar systems is shown in Figure 7. In this 
example there are separate adapter units which translate each system’s message into a common 
format. The messages are then sent and received over a common network or communication 
path. This quickly becomes a much superior solution to A-to-B Adapter Units when the number 
of dissimilar systems increases. 



Common Path Protocol, and Format 


Figure 7. Adapting To A Common Protocol And Format 
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For instance, the Common Interface could be an Ethernet port, the Common Path could be an 
Ethernet, the Common Protocol could be TCP/IP, and the Common Format is yet to be defined. 
However, an excellent candidate for the common format is the Joint Technical Architecture 
(JTA), which is a draft set of standards intended to help solve the C4I interoperability issues. To 
the degree that operational C4I systems migrate toward JTA to achieve operational 
interoperability, the adapter units become easier to develop. 

The optimum long-term solution from the M&S viewpoint is for C4I systems to have a separate 
input/output (I/O) port which can be used for testing during system development, manufacturing, 
and maintenance and as an I/O port which can directly (or via a low cost interface adapter) 
interface with the SE. The SE or a stimulator could stimulate the C4I system via this port, and 
the C4I system could provide outputs to the SE. A convenient format from the M&S perspective 
would be SEDRIS. The C4I system would translate its I/O based on the SEDRIS format, thus 
making it readily usable by multiple M&S systems. 

There are at least four distinct cases for integrating C4I systems with the SE: 

• Simulation of C4I systems, to provide data to the SE, 

• Stimulation of real C4I systems, to provide data to the SE, 

• Interfacing between range systems and the SE, and 

• Interfacing between live players and the SE. 

5.5.5.2.1 Simulation of C4ISystems 

The simulation of C4I systems ranges from a device, such as a SINCGARS Radio Emulator at 
the low end to simulation of the image from an unmanned aerial vehicle (UAY) at the high end. 
There is probably not a general solution for modeling C4I devices, however, the architectures 
shown in Figures 5, 6, and 7 are all appropriate for interfacing C4I simulations into the SE. 

5.5.5.2.2 Stimulation of Operational C4I Systems 

Operational C4I systems which are interfaced to the SE could be stimulated to provide data to 
the SE. Such systems range from the Single Channel Ground Air Radio System (SINCGARS) 
radios at the low end to JSTARS ground stations at the high end. There is a straightforward set of 
steps to approach this: 

• Determine the desired outputs from the C4I devices 

• Determine the required inputs to cause those outputs 

• Determine how to generate these inputs (e.g., record an audio tape and use a tape player 
for voice, record a video tape and use a video tape player for imagery, create on-line 
computer generated imagery, such as a Stealth display) 

• Determine how to interface those inputs into real C4I system 

• Implement the solution. 

5.5.5.2.3 Interfacing with Range Systems 

Range systems typically capture outputs from large numbers of players in an exercise. For 
instance, there are simultaneous voice transmissions on a number of radio frequency channels. 
There is also periodic position reporting by each of the vehicles involved in the exercise. There 
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can be video transmissions. Voice must be tagged with its transmission frequency or channel 
number when it is provided to the SE. Compatible radios or radio emulators in the SE must be 
able to set their receive frequency or channel number, and access a particular voice net. Vehicle 
position data must be translated into a format understandable by the SAFs or CGFs in the SE. 
Video transmissions could be channeled, as with cable TV. They could then be selected and 
viewed by live players in the SE, who have tuners and video displays. 

It may also be required to provide data from the SE back to range systems. This could occur in 
an exercise with live vehicles and players in a small area of the simulated battlefield, with a 
larger friendly virtual force on each side and a virtual opposing force. This is the same as Case 2 
- Stimulation of Operational C4I systems, where the scenario running in the SE must be used to 
provide correctly formatted information to the C4I systems, e.g., Applique, in the live vehicles. 
Surrogates are often the most economical way, at this time, to provide the SE generated voice 
and message traffic (e.g., commands downward and reports upward). 

5.5.5.2.4Interfacing with Live Players 

There are three primary ways to communicate with live players: voice, messages, and imagery. 
Voice, messages, and imagery from a live player require that the live player's C4I device (e.g., 
SINCGARS, Applique, etc.) be interfaced into the SE. This has already been discussed. 
Currently, to provide voice to a live player requires a live player in the SE to generate that voice. 
Messages (e.g., commands or situation reports) can be provided to the live player either from 
another live player or through an interface with the SE. Imagery can be provided from pre¬ 
recorded video tapes or from on-line computer generated imagery, such as a Stealth display. 

5.5.6 Numbers of Entities 

There can be a high cost for conducting a large simulated battle. Therefore, the approach to 
increase the number of entities must be balanced between the cost and the desired degree of 
realism. There are several approaches to increasing the numbers of entities in simulated battles. 
One is to use additional live entities (ground vehicles and aircraft) at a test/training range and 
link them into the SE. This approach incurs a high cost for each simulated battle. A second high 
cost approach is to procure additional copies of high fidelity training simulators, such as CCTT 
Ml or M2 vehicle simulators. A third approach that incurs significant development cost, but 
lower per unit acquisition costs, is to develop medium-fidelity reconfigurable simulators for 
classes of vehicles, i.e., one or more types for ground vehicles, one or more types for aircraft. A 
fourth approach is to procure lower fidelity COTS reconfigurable simulators, such as MAK Dial¬ 
a-Tank. This can become even lower cost if the software can be adapted by the vendor to run on 
PCs, instead of workstation class machines. A fifth approach is to utilize SAFs and CGFs to 
represent additional forces. 

The best approach for the Core DIS Facilities (CDF) and the battle laboratories is to determine 
how many and what types of simulators will suffice for the majority of their needs. This will 
allow economical tradeoffs to be made to meet those needs through combinations of cases 1-5. 

STRICOM’s role could be to work with each CDF and battle laboratory to determine their 
individual requirements, and then define an optimal consolidated approach. If developing one or 
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more classes of reconfigurable simulators is an economical alternative, STRICOM could be the 
leader in developing those simulators. 

5.5.7 Tools 

There are a number of areas where tools are required and where STRICOM could invest in 
creating tools. Four fundamental areas include tools for architecture, tools for an exercise starter 
kit, tools for exercise monitoring, and tools for after action reviews and post test analysis. 

STRICOM has invested heavily in the development and fielding of the HLA. This investment 
must continue to ensure a common architecture is achieved. Where possible, tools need to be 
developed that would help make HLA compliance easier. This would have broad reaching 
effects, because the community could used a tool set like this to help transition legacy 
simulations to HLA compliance. Continued development of tools is necessary to ensure that a 
common interchange between simulations is achieved. The SEDRIS program has been chartered 
to do this, but, requires, as with the HLA, continued funding and the directed use of SEDRIS as 
the common interchange format. 

A starter kit is required for use in exercise simulations. Oftentimes, these simulations require an 
expert user. If a starter kit is developed for simulations, then the user does not have to be an 
expert in any one simulation, but rather an expert in the training goal of the simulation. 

As the simulation is being conducted, there needs to be a way to gather data or monitor the 
simulation. This can be accomplished by having a “stealth” program running in the background, 
while the simulation is operating. Monitoring allows the user to know if the goal is being met or 
allows the user to terminate or restart if it is not. Also, monitoring allows for the gathering of 
data for after action review and post test analysis. Tools for assessing the success of the 
simulation are essential to objectively evaluate how well the simulation accomplished the 
training objective. When creating a new model or an extension of one, there needs to be a way to 
test its success. Often this is accomplished by regression testing - an authoritative data set is 
created and the new version is compared against the previous version. This type of testing 
should be accomplished for simulations. 

STRICOM’s role can be in the four areas above. By investing in architectures, starter kits, 
monitoring tools, and post test analysis tools, STRICOM could lead in simulation technology 
from the development to the execution to the review of a simulation. 
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6. SUMMARY AND CONCLUSIONS 

There were two contractual objectives for this effort. The first was to provide analysis and data 
for a plan to guide the direction of the synthetic environment (SE) development through the 
POM 98-03. The second was to provide STRICOM with a mid and long-range, high level 
strategic plan for synthetic environment development and execution. 

Research and data gathering were conducted to help identify the Army's major SE needs for FY 
98-03. That information was analyzed, consolidated, and prioritized to the extent possible. 
Completion of that activity fulfilled the first objective. Plans were then generated for how to 
meet each of the identified major SE needs. These plans are documented in this report and are 
also summarized in a companion viewgraph presentation. Completion of that activity fulfilled 
the second objective. 

The approach taken was determine the synthetic environment status and needs from 

• DoD and U.S. Army M&S policies, master plans, investment plans, and vision statements 

• Interviews with a wide variety of senior DoD and U.S. Army officials who are 
knowledgeable about and involved in various aspects of M&S policy, oversight, 
specification, development, and use 

• Other M&S professionals identified through research documents, reports, and referrals 

The inputs from these sources were consolidated into categories of issues. In parallel, enabling 
technologies were identified that can be applied toward solving the issues. 

Seven categories of SE issues were identified and prioritized. The top category was synthetic 
natural environment issues, especially problems relating to building and using terrain databases. 
The need for better representation of the behaviors of individuals, vehicles with crews, units, and 
commanders and their staffs was the number two category. The third category was the need for 
better interoperability between simulators. Fourth was the need for multipurpose, reconfigurable 
simulators. Better communications network models, and interfacing between C4I systems and 
the SE were fifth. Sixth was the need for more entities, to simulate larger fights between more 
diverse units. The remaining category was tools to make it faster and easier to build the SE, 
design and set up experiments, collect data, and analyze results. 

Eight categories of enabling technologies were identified as being particularly relevant to 
developing an improved SE. They were architectures, computers, display devices, display 
generators, man machine interface devices, networks, software, and tools. 

Execution plans were defined and documented for applying each enabling technology toward 
solving the SE issues. To effectively implement these plans probably requires a staff of technical 
experts who report to a manager who is above the Program Managers. Someone at that level is 
needed to make and enforce decisions that may impact one program negatively, but are best for 
the programs as a whole. 

Execution plans were defined and documented for addressing each of the SE issues. 
Implementing these plans must be accomplished within the business environment that 
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STRICOM operates. This will involve tradeoffs among the priority assigned by higher level 
commanders, the estimated cost, funding availability, the potential benefit, the urgency of the 
time frame, and the development risk. 

The existence of these SE issues presents an opportunity for STRICOM to provide the leadership 
to solve them for the benefit of the Army M&S community. To accomplish this, STRICOM must 
be address five issues: 

1. Implementing the solutions will require an appropriate pool of skilled technical people. 

When there are identified solution approaches, the technical risk is low. 

2. Funding must be found to implement each solution. Since the problems needing to be solved 
span all three domains, the possibility exists to solicit and pool resources from a number of 
organizations. Also, a pricing strategy is needed that allows STRICOM to earn profits on the 
programs it executes. This profit would become working capital and investment capital. This 
is a normal practice in all businesses. 

3. An organizational structure is needed within STRICOM that will encourage, facilitate, and 
when necessary enforce cooperative developments and reuse across its projects. 

4. A contractual mechanism is needed between STRICOM and the program funding 
organizations that will allow STRICOM to earn, use, and invest profits. 

5. Develop strategic alliances with key government and industry organizations. 

A broader leadership opportunity would be to move beyond a focus on training simulators and 
seek to provide a common SE and common applications across all three domains: ACR, RDA, 
and TEMO. The broadest leadership opportunity is to provide well-organized, high quality 
leadership to the entire M&S community, and target becoming the Simulation Center for the 
Army. 
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APPENDIX A 

LETTER AND SURVEY QUESTIONS 
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SURVEY QUESTIONS 


1. Where do you think the Army should get to in Models and Simulations (M&S) capability 
over the next five years? 

2. What can STRICOM do in the area of Synthetic Environments (SE) that would most benefit 
your organization or program? In what time frame do you need it? 

3. What do you see as the top breakthrough opportunities in SE? The key enabling technologies 
for those breakthroughs? 

4. For which SE related items would you strongly recommend that development continue or 
accelerate? 

5. What do you think are the SE related problems that most need addressing? In what time 
frame are solutions needed? 


6. For which SE related items would you recommend that current development be halted or 
redirected? 


7. What other input can you provide that would help in formulating a Synthetic Environment 
Strategic Plan for STRICOM? 
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APPENDIX B 

CONTACT LIST 
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CONTACT LIST 

Allison, Julie Standards Category Coordinator - Mobilization 301-295-1588 

Director, USA CAA ATTN: CSCA-OS 
8120 Woodmont Ave 
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Bauman, Michael F. Director, Attn: ATRC 913-684-5132 

US Army TRADOC Analysis Command 
Ft. Leavenworth, KS 66027-5200 

Bernay, Dorothy Standards Category Coordinator- Cost Representation 703-681-3347 

Dir, USAA Cost & Economic Analysis Center 
ATTN: SFFM-CA-PA Rm. 327, Nassif Building 
5611 Columbia Pike 
Falls Church, VA 22041-5050 

Blair, Alex Standards Category Coordinator - Logistics 804-734-0322 

USACASCOM ATTN: ATLC-CAT 
Fort Lee, VA 23801-6000 

Bradley, Brad Standards Category Coordinator - Object Management 410-278-4066 
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Aberdeen Proving Ground, MD 21005-5071 
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3701 N. Fairfax Dr. 

Alexandria, VA 22203-0000 
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3909 Halls Ferry Road 
Vicksburg, MS 39181-6199 

Caldwell, Doug Rapid Construction of Virtual Worlds, USATEC 703-428-6719 
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Washington D.C., 20310-0103 
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Gardner, Nancy Terrain Data Base Generation and Development (USATEC) 703-428-6954 
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Attn: ATZK-MW 
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1725 Jefferson Davis Highway Suite 808 
Arlington, VA 22202 
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12350 Research Pkwy 
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407-384-3926 
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Synthetic Environments Evaluation and Demonstration Site 703-428-6651 
USATEC 


Inge, Joseph (BG) Deputy Commandant 913-684-3443 

US Army Command and General Staff College 

1 Reynolds Avenue 

Ft. Leavenworth, KS 66027-1352 

Koklauner, Karl Program Manager, USATEC 703-428-6845 

USATEC Synthetic Environments 

Kunkel, Burt Standards Category Coordinator - C3 Systems 706-791-1977 

Representation 

Modeling & Simulation Branch Concepts and Architecture Div 
Directorate of Combat Developments 
Ft Gordon, GA 30905-5090 


Larocque, Robert (Dr) Attn: ATZL-CTS 

Director, National Simulation Center 
246 Kearny Avenue 
Ft Leavenworth, KS 66027-7000 
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ATCD-B Building 163 

Ft. Monroe, VA 23651-5000 


Miller, Duncan (Dr) MIT Lncoln Lab 


781-981-7452 


54 

Use or disclosure of information on this page is subject to the restrictions referenced on cover of this report 

UNCLASSIFIED 



ADST-II-CDRL-SESP-9800192 

7/15/98 


Mullane, Kevin 

Integrated CGF Terrain Data Base Representation in DIS 
USATEC 
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GLOSSARY OF ACRONYMS 


ACR 

Advanced Concepts and Requirements 

ALSP 

Aggregate Level Simulations Protocol 

AMG 

Architecture Management Group 

AMSEC 

Army Model and Simulation Executive Council 

AMSO 

Army Model and Simulation Office 

API 

Application Program Interface 

AU 

Adapter Unit 

BBS 

Brigade/Battalion Battle Simulation 

CCTT 

Close Combat Tactical Trainer 

CECOM 

Communications and Electronics Command 

C4I 

Command, Control, Communications, Computers, and 
Intelligence 

CGF 

Computer Generated Force 

CIG 

Computer Image Generator 

COTS 

Commercial-off-the-Shelf 

CPAF 

Cost Plus Award Fee 

CRT 

Cathode Ray Tube 

DIS 

Distributed Interactive Simulation 

DMSO 

Defense Model and Simulation Office 

DoD 

Department of Defense 

EXCIMS 

Executive Council on Modeling and Simulation 

GUI 

Graphical User Interface 

HLA 

High Level Architecture 

I/O 

Input/Output 

JSIMS 

Joint Simulation System 

JSTARS 

Joint Surveillance Target Attack Radar System 

JTA 

Joint Technical Architecture 

JWARS 

Joint Warfare System 

LAN 

Local Area Network 

LCD 

Liquid Crystal Display 

ModSAF 

Modular Semi-Automated Forces 

MRCI 

Modular Reconfigurable C4I Interface 

M&S 

Models and Simulation 

MSO 

Mission Space Objects 

OPFOR 

Opposing Forces 

OPSIN 

Operational State Interpreter 

OSD 

Office of the Secretary of Defense 

PM 

Program Manager 

RDA 

Research, Development and Acquisition 

RF 

Radio Frequency 
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